Sui Portfolio Tracking: The Object-Centric Coin Model

What sets Sui apart is that a balance is not a number that decrements; it is a set of distinct Coin objects, and sending tokens splits one object into two. When Alice sends 1 SUI to Bob, her Coin object is split: one object remains with her holding the change, and a brand-new object holding the sent amount goes to Bob. So a Sui holding is a collection of objects that split and merge over time, and tracking it means following object lineage and aggregating those objects into a logical balance, not reading one balance field. This is a step beyond even the account-model resources of Aptos, because on Sui the unit of state is the object itself. This article covers what that object-centric model changes for reconciliation. It is one of the non-EVM cases gathered in the multi-chain aggregation hub.

The object model in brief

• Sui is object-centric: a token holding is one or more Coin objects, each with its own identity, not a balance entry.
• A SUI transfer splits a Coin object into two: a remainder object and a new object for the amount sent.
• Tracking must follow split and merge lineage and aggregate owned Coin objects into a logical balance.
• Owned-object parallelism reinforces that the object is the unit of state, so you reconcile at object level then aggregate.
• Cost basis and tax are unchanged: the jurisdiction method applies; only the data model differs.
• A balance-mapping tracker mishandles Sui, so it must model objects or it mis-reconciles every transfer.

Objects all the way down

Where an EVM chain has balance mappings and an Aptos account holds resources, Sui organises assets as unique objects, each with its own identity. A token holding is one or more Coin objects owned by an address, not a single balance field. The unit of state is the object: that is the whole model, and the basis of every tracking decision on Sui.

A transfer splits an object

The defining mechanic is that a native SUI transfer is object manipulation, not a balance update. When Alice sends 1 SUI to Bob:

• Alice's existing Coin object is split into two;
• one object remains with Alice holding her remaining balance;
• a new Coin object is created holding the transferred amount and goes to Bob.

A tracker that expects "Alice's balance decreases by 1" is modelling the wrong thing. It must follow split-and-create, tracking both the new object and the remainder.

Why this complicates tracking

A Sui holding is a set of objects that split and merge over time, not a stable number. Reconciliation must:

• aggregate all owned Coin objects of a type into a logical balance;
• follow object lineage, tracking which object resulted from which split or merge;
• avoid double-counting or losing an object across a split.

This is a different completeness problem from "one balance per token," closer to following DeFi position decomposition than reading an EVM wallet.

Step-by-step: how to track a Sui portfolio

1. Enumerate owned Coin objects per address. Use the suix_getCoins RPC method (or the equivalent getAllCoins) to list all Coin objects of each type owned by the address. Each result includes the object ID, balance amount, and coin type.
2. Aggregate coins of the same type. One address may own dozens of 0x2::sui::SUI Coin objects with small balances (from change outputs and small splits). Sum them by coin type to get the logical balance — but track each object ID for lineage.
3. Fetch transaction history. Use suix_queryTransactionBlocks filtered by the address as sender or recipient. For each transaction, inspect the objectChanges array: look for mutated, created, and deleted entries to understand how objects were split, merged, or transferred.
4. Map split/merge lineage. A sui::pay::split transaction produces a new Coin object (created) from a parent (mutated). A merge produces a deleted source and a mutated target. Track previousVersion in each object change to reconstruct the lineage graph.
5. Classify DeFi interactions. Protocol calls (DEX swaps, staking) appear as MoveCall transactions. The coin objects consumed and created by the call represent the economic flows. Read the type tags to determine which assets were exchanged.
6. Identify and deduct gas fees. Sui gas is paid in SUI. Every transaction's gasData.budget and gasData.price yield the maximum fee; the actual fee is in effects.gasUsed (computationCost + storageCost - storageRebate). Deduct the net fee from the SUI cost basis pool.
7. Apply the jurisdiction cost-basis method to the classified history; classify own-address internal transfers as non-disposals.

Common errors and how to fix them

Error 1 — Missing fragmented Coin objects. If a tracker fetches only the largest Coin object per type it under-counts the balance. Users accumulate dozens of small-value SUI objects from DeFi activity. Fix: always aggregate all Coin objects of a type, not just the first result.

Error 2 — Double-counting a merge. When two Coin objects merge, the consumed object is deleted and the receiving object grows. A naive tracker that reads both the deletion and the addition as separate events records a phantom receipt. Fix: pair deleted and mutated entries in the same transaction's objectChanges — if both affect the same coin type in the same tx, it is a merge, not a transfer.

Error 3 — Treating a split as a disposal. Splitting a large Coin into several smaller ones is an administrative operation — it does not transfer ownership to a third party. Some trackers incorrectly flag the created objects as incoming acquisition events. Fix: check the transaction's sender matches the recipient of the created objects; if yes, it is a self-split, not a disposal.

Error 4 — Incorrect storage rebate accounting. Sui charges storage fees but refunds a portion when objects are deleted. Ignoring the rebate (storageRebate in gasUsed) overstates the SUI cost of each transaction. Fix: compute net gas as computationCost + storageCost - storageRebate for each transaction.

Parallelism reinforces the model

Sui can process transactions on distinct owned objects in parallel, with no shared-state contention, and simple owned-object transfers can bypass full consensus. That is a performance property, but for tracking it reinforces the core point: the object, not a global balance, is the unit of state. Reconcile at the object level, then aggregate to a position.

Tax unchanged; aggregation is the work

Sui does not change the cost-basis method, which is still the jurisdiction-mandated one. It changes the read model. The work is to:

• aggregate owned Coin objects into a logical position;
• follow split and merge lineage for correctness;
• classify internal transfers between your own Sui addresses as non-disposals (see internal transfer vs disposal).

Practical guidance

1. Model holdings as sets of Coin objects, not a balance field.
2. Follow split-and-create on every transfer — track the new object and the remainder.
3. Aggregate owned objects of a type into the logical balance.
4. Track object lineage to avoid double-count/loss across splits/merges.
5. Apply the jurisdiction cost-basis method; classify internal transfers as non-disposals.
6. Reconcile at object level to the chain, then aggregate, with an audit trail.

Choosing a tool for the object model

Koinly and Zerion both support object-model chains, but the Sui-specific checks before you trust the numbers are:

• it aggregates every owned Coin object of a type, not just the largest, since DeFi activity leaves a wallet holding dozens of small-value objects;
• it pairs the deleted and mutated entries of a merge so a merge is not read as a phantom incoming receipt;
• it recognises a self-split (sender equals recipient of the created objects) as an administrative operation, not a disposal;
• it accounts for the storage rebate when computing gas, so a transaction's SUI cost is not overstated;
• it treats internal transfers between your own Sui addresses as non-disposals.

A balance-only tracker that expects one number to decrement will misread every Sui transfer.

How Wag3s handles Sui wallets

Wag3s Folio models Sui holdings as sets of owned Coin objects, follows split-and-create lineage on transfers, pairs merges and self-splits correctly, accounts for the storage rebate in gas, and applies your jurisdiction's cost-basis method with internal transfers classified as non-disposals. See the Folio product page.

Further reading

• Aptos Portfolio Tracking
• Solana Portfolio Tracking
• Multi-Chain Portfolio Aggregation Beyond EVM
• Multi-Chain Reconciliation
• Crypto Cost Basis Methods 2026
• Internal Transfer vs Disposal in Crypto

Sources

• Sui — Object Model: assets are organised as unique objects, each with its own identity, as the fundamental unit of storage.
• Sui — Module sui::coin and Module sui::pay: the Coin type and the split, join, and transfer operations that drive the split-and-create transfer mechanic.
• IRS — Digital assets for the US cost-basis and disposal framework applied to the resulting data, not the chain.