LibraryConsensus2022Design paperCorpus record
The Sui Smart Contracts Platform
Sui. The Mysten Labs Team.
Mysten Labs' platform paper. Assets are Move objects. Operations on objects owned by a single address can finish by consistent broadcast among validators. Shared objects go through consensus. The split is the design.
Sui's paper claims that an object a single owner holds can be committed without going through a total order with every other object. Shared objects still take the slower consensus path.
The five-minute read
Objects, not accounts, are the state
The ledger is a set of typed objects with owners. A transaction names the objects it will touch. If it names them, the protocol knows whether a global order is required.
Owned objects take a fast path
If an object has one owner, and the transaction only touches objects that owner holds, validators can sign it without agreeing on an order against unrelated transactions. Causal order is enough.
Shared objects take consensus
Anything two parties might touch at once goes through a Byzantine total order. The paper does not claim that every transaction skips consensus. It claims that many do.
Move enforces ownership in the type
The language is how 'this object has one owner' stays true as code evolves. A fast path that the type system does not police is just an honour system.
The split is the product decision
Games and simple transfers fit owned objects. An order book does not. A pitch that quotes the fast path for a shared-state application is quoting the wrong paragraph.
One action, walked through
- A user builds a transaction that lists the object identifiers it reads and writes.
- If every object is owned by that user and no shared object is involved, validators check the owner's signature and the object versions, then sign.
- A quorum of those signatures is a certificate. The transaction can be executed from the certificate.
- If any object is shared, the transaction is ordered by the consensus protocol first, then executed in that order.
- The resulting objects have new versions. A later transaction that names a stale version fails.
The argument, unpacked
Causal order is not 'no consensus'
The fast path still needs a quorum of validators. It skips a total order among independent transactions. It does not skip trust in the validator set. An attacker who can forge a quorum can forge either path.
Versioning is the double-spend protection
An owned object has a version. Two transactions that name the same version cannot both gather certificates. That replaces the usual nonce-on-one-account model. Wallets that do not track versions will confuse users even when the protocol is correct.
Shared state is where the system becomes ordinary
The moment an application uses a shared object, latency looks like other Byzantine chains. The paper's contribution is to make that moment explicit. Hiding shared objects inside a framework, so developers think they are on the fast path, undoes the honesty of the design.
What has to be true
- Validators are the same quorum you would trust for a normal chain. The fast path is not a lighter trust assumption.
- Object ownership is enforced by execution, not only by the transaction's claim.
- Clients learn certificates and new versions reliably. A client who misses a version is stuck until it catches up.
- The consensus path for shared objects is live. A deadlock there freezes every shared application even while owned-object transfers still work.
What happened after the paper
Sui launched with this object model and later tuned consensus for the shared-object path. The distinction between owned and shared remains the paper's real teaching. Marketing that says every transaction avoids consensus is not the paper.
What to check before you use the idea
- Does this application touch a shared object on the hot path?
- What quorum signs an owned-object certificate?
- How does a client discover the current version of an object?
- What is the latency of the shared path, stated separately from the owned path?
Terms
- Owned object
- A piece of state with a single owner. Transactions on it can be certified without a global order against other owners.
- Shared object
- A piece of state more than one party may touch. It is sequenced by consensus.
- Certificate
- A quorum of validator signatures on a transaction, sufficient to execute an owned-object call.
- Object version
- The counter that makes a second spend of the same state fail, because the stale version no longer certifies.
The problem the paper names
Most chains put every asset transfer through the same total order as every other transfer. Sui's claim is that an object with a single owner does not need that total order. It needs a check that the owner signed, and that validators agree the object version advanced once.
What the design proposes
- Objects have owners, versions and types. Move defines how they are created and transferred.
- Owned-object transactions use a Byzantine consistent broadcast path.
- Shared-object transactions use a consensus path, because more than one party may touch them.
How the mechanism is specified
- The certificate of a transaction lists validator signatures on that specific object version.
- A later transaction on the same object must name the new version. That is the double-spend check.
- A separate economics note exists. This page is about the platform paper, not the token schedule.
What this page does not treat as proven
- The fast path disappears as soon as the object is shared. Many applications will share state and should not quote the fast path.
- The paper does not measure the live network, and neither does this page.
- Move's safety properties are only as good as the modules people actually publish.
Why a venture studio still reads it
This is the clearest recent statement of a question we ask ventures: does this asset have one owner right now? If yes, do not make it wait behind a global auction. If no, stop claiming the fast path.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.