#03: Understanding Sui Move’s "Object-Centric Model": Comparing UTXO and Account-Based Model
- crypt0crypt0
- Jun 7
- 9 min read
Premise: Why should we learn about "data management models"?
A blockchain is a ledger that continuously records the "state," meaning "who has what, and how it has changed."
For example, how many coins does a certain address have? Who owns which NFTs? What contracts were made, and what is their history? All these are "states." Moreover, depending on how this "state" is managed, the blockchain's design, usability, and potential significantly change.
In Bitcoin, coins are managed just like physical cash placed on a cash tray, creating a chunk of "new change" each time a payment occurs. In Ethereum, balances and contracts are treated like bank accounts. Sui, however, differs from these, having a structure that treats assets and data as actual "objects."
Understanding this "difference in how data is held" is an extremely important perspective for both developers and business professionals when considering what to build on which blockchain. This article compares three models, unraveling the background and possibilities of the "object-centric model" adopted by Sui.
1. Bitcoin: The Basics and Limitations of the UTXO Model
In Bitcoin, the money you hold is not managed collectively as an "account balance." Instead, it has a structure where multiple small "bundles of cash" exist separately. These bundles are called UTXOs (Unspent Transaction Outputs). It may be helpful to imagine a cash tray placed next to a cash register.
Referring to the figure above, imagine a scene where Alice makes a payment to Bob. In front of Alice, there's one $10 bill and one $5 bill placed on a tray. These are the two UTXOs Alice owns. At some point, Alice wants to pay $12 to Bob. She has a $10 bill and a $5 bill in hand. So, Alice gives the two bills to Bob and receives $3 as change. At this moment, the original two bills are spent, and instead, new trays are created—one for the "payment" and another for the "change."
In Bitcoin, the state changes in this manner: "UTXOs are consumed as inputs, and new UTXOs are created as outputs." A transaction explicitly describes "which UTXOs are being used (inputs)" and "what kind of UTXOs result (outputs)." In other words, a single transaction has the following structure:
Inputs: Previously unused UTXOs (the "source" of the money)
Outputs: Newly issued UTXOs (payments and change)
This structure is very simple; once input UTXOs are consumed, they become completely unusable and cannot be reused. Thus, it is easier to avoid fraudulent activities such as double spending, and because multiple UTXOs are independent, they are suitable for parallel processing. Additionally, validating a transaction simply involves checking if the inputs are unused and if the signature meets the required conditions.
However, there are several limitations with this approach. For example, since a UTXO is merely a "set of amount and ownership information," it does not inherently have state or code. Therefore, it is not suitable for managing complex data structures like NFTs or assets with contractual conditions. Additionally, to verify how much assets you own, your wallet must automatically scan and sum all UTXOs. Moreover, since each output is individually recorded, the amount of data stored on the blockchain tends to grow large, making node synchronization slower. When making transfers via smart contracts, you must manually specify which UTXOs to use and handle change yourself, making the design more complicated.
In this way, Bitcoin’s design is very effective for "transferring" and "storing value," but it can feel restrictive for the dynamic and complex application structures required by Web3. For this reason, the next model created was the "account-based management model" used by Ethereum and Solana. How exactly is this model different?
2. Ethereum and Solana: The Flexibility and Ingenuity of the Account Model
In Bitcoin, money was divided into small bundles and placed on a “cash tray.” But Ethereum and Solana take a completely different approach. That is, a system like a “bank account.”
For example, there is one account in your name, and $100 is deposited in it. Every time there is a payment or receipt, the balance of that account increases or decreases. This is the basic image of the account model.
In Ethereum, for instance, when Alice sends $8 to Bob, the state is updated: Alice’s balance changes from $10 to $2, and Bob’s balance changes from $1 to $9. This is what it means to “update the state of the account.”
In Ethereum, it's not just money that’s stored in an account. Contracts, conditions, and even transaction history are also stored as the “state held by the account.” In other words, the account is not just a container for numbers, but it behaves like a small computer. Thanks to this structure, we are able to write programs called smart contracts, set rules for transferring funds, and carry out automated transactions. DeFi, NFTs, and DAOs all rely on this flexible account model.
However, this freedom comes at a cost.
In Ethereum, because all state is grouped by “account,” if multiple transactions attempt to operate on the same account, conflicts between data can occur. This makes parallel transaction processing difficult, leading to gas fee spikes and waiting times. It’s like a rush of people crowding into a single service window, resulting in a long line.
To address this issue, Solana introduced structural ingenuity.
In Solana, in a scenario where Alice, who has $10, sends $8 to Bob, she pre-declares “which accounts will be read or written (Reads/Writes)” and “which program will be executed (Program).” In banking terms, it’s like saying from the start: “I will read the balance of my account number 12345 and transfer to another account 56789.”
Thanks to this prior declaration, the network can determine, “this operation and that operation involve different accounts, so it’s safe to process them simultaneously,” enabling parallel processing. Furthermore, Solana strictly separates “accounts” and “programs.” Code is code, data is data. This allows a single program to operate on the state across multiple accounts, enabling more structured applications.
That said, this requires proficiency. To build applications on Solana, developers must pre-design which accounts play what roles and how they are combined. Compared to the high flexibility of Ethereum, it demands more rigorous architectural thinking.
3. Sui: The Emergence of the Object Model and a Shift in Thinking
Now, let’s finally take a look at the main topic—Sui’s object model.
We described UTXOs as bundles of cash on a cash tray, and the account model as the balance in a bank account. In contrast, the model adopted by Sui is like directly handing over the “cash itself.”
In Sui, money, items, and contracts all exist in the form of “objects.” These objects are small “things” that carry information such as ID, owner, contents, and type—like a banknote with a serial number or a game item.
For example, your wallet contains one “$10 coin object (Object 1).
”It has an ID of 0x111, is owned by you (Alice), and holds a value of $10.
When you use this object to send $8 to someone, the original Object 1 is consumed (discarded), and two new objects are created:
One is Object 2 holding the remaining $2 (owner: Alice, ID: 0x222),
The other is Object 3 holding $8 (owner: Bob, ID: 0x333).
In the figure above, the old object (Object 1) that Alice had is consumed, and new objects are generated for Alice and Bob.
Here, there is no abstract operation such as rewriting the numbers in an account. It is purely a matter of “objects being moved, created, and the old ones discarded.”The appeal of this structure lies first in its intuitive sense of ownership. It aims to represent in the digital world the real-world feeling of “what I own is clearly right here.”Naturally, this applies to digital items like NFTs, but even a user’s state or contracts can be handled as “objects.” As a result, data on the blockchain can be treated not as abstract information but as “tangible things.”
Also, in Sui’s foundational design, when payments like the one above are made, new Object IDs are generally created through splitting (split) or transferring (transfer). However, there are exceptions where the Object ID does not change.For example, with operations like adding “another object as an internal field” to an NFT equipment item, the parent object is passed as mutable (mut), and only its contents are updated while the original ID is maintained.In this way, if you’re merely updating the state of a field, the original Object ID can continue to be used.
This design enables the construction of highly expressive smart contracts—one of Sui Move’s key strengths.
Furthermore, Sui defines three ownership modes (technically speaking four) depending on the object type:
Owned: An object that is individually owned. It is linked to either a personal account or another object. Coins and NFTs fall into this category. There are two types: “account-owned” and “object-owned.”
Shared: An object that can be read and written by multiple people at the same time. Used in things like DAO voting boxes or marketplaces. Requires consensus for global ordering.
Immutable: A read-only object that cannot be changed once created. Used for things like token metadata. This is also a type of Shared Object, but if it’s only read, anyone can access it.
This ownership model enables Sui to achieve a high-level balance of security, expressiveness, and parallelism.
Another major feature of Sui is its mechanism for parallel execution. In Sui, all transactions explicitly declare which objects they will read or write.
Because of this, the network can determine, “These two operations handle different objects, so it’s safe to process them simultaneously.”
In particular, Owned Objects do not require consensus, enabling fast parallel processing.This means developers do not need to worry about complex parallel control. The network itself will automatically optimize and handle non-conflicting transactions.
In Sui’s world, data is no longer “just a number locked inside someone’s account.”It is a thing—owned, moved, and sometimes discarded, with real behavior.
What kind of possibilities might this way of thinking bring to the future of Web3 and AI agents?
In the next chapter, we’ll explore the future that Sui’s “objects” are poised to unlock.
4. Why Sui's Object Model Builds the Future
With the introduction of the object model, Sui has brought unprecedented flexibility and clarity to state management on the blockchain. Its biggest feature is a design that modularizes state and gives each one an ID, type, owner, and lifecycle. This allows different targets—such as assets, data, and contracts—to be treated within a shared abstract structure.
The meaning of this structure goes beyond technical advantages like "easy development" or "parallel processing."
It is also an attempt to redefine the relationship between data and code in Web3.For example, in conventional models, state is hidden inside accounts, and referencing or operating it externally requires abstracted APIs.
However, in Sui, the state is the object itself, and it is represented as a unit that can be directly owned, transferred, or modified on the network.
This design of “open state” has strong compatibility with next-generation use cases such as:
Asset management and contract execution by AI agents → Because there is a general structure that can recognize and operate on objects
Cross-application inheritance and behavioral linkage of owned items → The same object can be reused in different contexts
Conditional sharing of state through programs → Can be realized by combining Shared objects with access controls
BTCFi construction → Since Bitcoin’s UTXOs and Sui’s objects are both “distinct and separable units of value,” they align structurally → When BTC is introduced to Sui via token wrapping or bridges, the ability to track and control it as a discrete asset unit becomes a strength
Furthermore, because these object operations are managed with type safety and explicit control in Sui Move, scalability and security can be maintained at the same time.
Sui’s object model is more than just a technical invention—it's a restructuring of digital assets, states, and contracts.In that sense, this represents a paradigm shift in how we build blockchain applications.In the next chapter, we’ll gently outline where to start for those who want to understand this structure more deeply.
5. For Those Who Want to Learn More: A Gentle Path to Study
If you’ve read this far, you’ve likely already felt it:
The “object model” adopted by Sui is not just a technical topic, but a shift in the very way we think about blockchains.
Data moves from being a “record” to a “presence.”
Balances shift from being “numbers” to “things.”
Contracts evolve from “commands” to “behaviors.”
It’s a design philosophy that shortens the distance between code and the real world—just a little.
Of course, there may still be parts you don’t fully understand yet. And that’s perfectly okay.If you find yourself wanting to explore this model further, start by taking a look at Sui Move, the programming language behind it.
In this language, behaviors like “passing objects,” “transferring ownership,” and “safely changing state” are carefully expressed at the code level.
Or you could read Sui’s documentation and follow topics such as transaction mechanisms, Shared object design, and the concept of parallel execution.At first glance, these may seem difficult—but the “structural understanding” you now have will surely help you decode them.
For those who want to go even deeper, here are some recommended themes:
Why does Sui Move explicitly include the concept of “deletion”?
How is parallel execution determined? (What are non-dependent objects?)
Technologies like Seal or Nautilus that link objects with privacy
All of these are part of Sui’s ecosystem design for making data “come alive.”Sui is not just a “high-speed chain.”It’s a structural approach to redefining data as assets, and for the next generation of developers and product designers, it is a way of thinking worth learning.
What you’re studying isn’t just the language or the protocol, but the logic and philosophy that the structure supports.Holding on to that perspective will surely become a strong weapon in designing the Web3 of the future.
ーーーーーー