Sui Portfolio Tracking: The Object-Centric Coin Model

Sui takes the "tokens are objects" idea to its conclusion: a balance is a set of Coin objects, and a transfer splits an object in two. Neither an EVM balance nor an account-model resource view reconciles this correctly. This guide is the object model and how to track a Sui portfolio.

TL;DR

• 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/merge lineage and aggregate owned Coin objects into a logical balance.
• Owned-object parallelism reinforces that the object is the unit of state — reconcile at object level, then aggregate.
• Cost basis/tax unchanged — the jurisdiction method applies; the data model differs.
• A balance-mapping tracker mis-handles Sui — model objects or mis-reconcile.

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: 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 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 — which object resulted from which split/merge;
• avoid double-counting or losing an object across a split.

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

Parallelism reinforces the model

Sui can process transactions on distinct owned objects in parallel (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 — still the jurisdiction-mandated one. It changes the read model. The work:

• aggregate owned Coin objects into a logical position;
• follow split/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.

How vendor tools handle Sui

Koinly and Zerion support object-model chains. Confirm the tool models Coin objects and split/merge (not a balance mapping), aggregates owned objects into a position, follows object lineage, and treats internal Sui transfers as non-disposals — a balance-only tracker will misread every Sui transfer.

How Wag3s helps

Wag3s Folio models Sui holdings as sets of owned Coin objects, follows split-and-create lineage on transfers, aggregates objects into a logical position, 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-centric data model (assets organised as unique objects with their own identity)
• Sui native transfer mechanic — a Coin object is split into two (remainder + a new object for the transferred amount)
• Owned-object parallel execution (distinct objects processed in parallel; simple owned-object transfers can bypass full consensus)