suiboxer.xyz

Sui and Aptos

The Move language was created at Meta (then Facebook) for the Diem blockchain project. When Diem was abandoned, the technology did not die. Two independent teams took the Move virtual machine and built production blockchains around it: Aptos and Sui. Both chains run Move. Both claim parallel execution, low latency, and safety as their core advantages. But they made radically different design choices about how data is stored, how transactions execute, and what developers need to learn.

This page is the map. Below it are seventeen spoke pages, each answering one specific question in detail. You are here to understand the landscape. When you hit a topic that matters to you, follow the handoff.

The language that changed the rules

Before Move, smart contract languages like Solidity treated digital assets as numbers in a ledger. A token was a balance in a map. If you could increment or decrement that number, you had moved the asset. Move treats assets as resources: they cannot be copied, cannot be silently discarded, and can only be moved by explicit transfer logic. This is enforced at the bytecode level, not by convention.

Both Sui and Aptos inherit this safety model. But they implement Move differently. The differences matter enough that code written for one chain will not compile on the other without changes. The spoke page Move on Sui vs Move on Aptos The Real Dialect Differences walks through the concrete syntax divergences and framework changes you will encounter when porting code.

A common misconception is that Sui Move and Aptos Move are the exact same language. They are not. Sui modified the core Move language to support its object model. Aptos stayed closer to the original Diem version but built a rich standard library on top. Both are Move. Neither is interchangeable.

For developers coming from Ethereum, the shift is larger than the syntax. The spoke page Move vs Solidity How Move Language Chains Compare to EVM Development explains how the resource model changes everything from token standards to upgrade strategies. If you have only written Solidity, start there.

Data models: the fundamental fork

The single most important difference between Sui and Aptos is how they store state.

Aptos uses a global storage model inherited from Diem. Every piece of data lives under an account address. To read any value, you look it up by address and key. This is familiar to anyone who has used a key-value store. Transactions can access any data in global storage, and the system uses Block-STM optimistic concurrency to execute transactions in parallel, re-executing any that read stale data.

Sui does not have global storage in the same sense. Data lives in objects, and each object has an owner. The owner can be an address, another object, or a shared group. Transactions declare upfront which objects they will access. Because the set of objects is known before execution begins, Sui can schedule non-conflicting transactions in parallel without re-execution. Objects that are owned by a single address do not need consensus at all - they can be processed by a single validator.

The spoke page Sui Object Centric Data Model How It Differs From Global Storage explains how Sui's object model works in practice and why it changes everything from fee calculation to transaction design. The spoke page How Parallel Transaction Execution Works on Aptos With Block STM covers the technical details of Aptos's approach and compares it to Sui's object-based parallelism.

If you are deciding between the two chains, the data model is the first question. The spoke page Sui or Aptos Which Move Chain Should You Build On walks through the tradeoffs for different project types. There is no universal answer. Object-centric storage is better for applications where ownership is clear and most transactions touch few objects. Global storage is better when you need to scan or aggregate data across many users.

Consensus and Finality

Both chains claim sub-second finality. They achieve it through different mechanisms.

Aptos uses AptosBFT, a variant of the HotStuff consensus protocol. It requires two rounds of communication between validators before a block is committed. In practice, transactions finalize in under a second under normal conditions. The spoke page AptosBFT Consensus How Aptos Achieves Sub Second Finality explains the protocol and how it handles validator failures.

Sui originally used Narwhal and Bullshark, a mempool and consensus protocol designed to decouple data availability from ordering. In 2024, Sui transitioned to Mysticeti, a DAG-based consensus that reduces latency further. Mysticeti allows validators to commit blocks in a single round under happy-path conditions. The spoke page also covers this comparison.

For end users, the difference is not noticeable. Both chains feel instant. For validators and infrastructure operators, the consensus choice affects hardware requirements, staking mechanics, and reward distribution. The spoke page AptosBFT Consensus How Aptos Achieves Sub Second Finality includes a section on Mysticeti for Sui.

Accounts, wallets, and onboarding

The user experience of creating an account and keeping it safe is different on each chain.

Aptos uses a traditional account model where a private key controls an address. The key can be rotated - you can replace the public key associated with your account without changing your address. This means you can recover from a compromised key without losing your on-chain identity. The spoke page Aptos Account Model and Key Rotation How to Secure Your Address explains the mechanics and the risks of rotating to a key you later lose.

Sui also supports key rotation, but its account model is simpler because the object system does not require accounts to own a balance for every interaction. Sui wallets like Sui Wallet and Nightly Wallet are the primary tools for interacting with the chain. For Aptos, Petra Wallet and Martian Wallet serve the same role. Both sets of tools are listed in the entity inventory as volatile - they change frequently, and you should check current documentation before relying on them.

Both chains have introduced passkey-based onboarding to eliminate seed phrases. Sui calls it zkLogin. Aptos calls it Keyless accounts. Both use zero-knowledge proofs to let users authenticate with an OAuth provider (Google, Apple) while retaining self-custody. The spoke page Sui zkLogin vs Aptos Keyless Accounts Which Onboarding Is Easier compares the two approaches. The key risk is that sealed wallet passkey loss with no exportable private key can permanently lock funds. Neither system is a silver bullet.

Building on Move: Tools, Transactions, and Gas

Programmable transaction blocks and sponsored transactions

Sui's Programmable Transaction Blocks (PTBs) let you combine multiple operations into a single atomic transaction without deploying a smart contract. You can, for example, swap tokens, deposit into a lending pool, and mint a receipt in one PTB. The spoke page Sui Programmable Transaction Blocks How PTBs Combine Multiple Operations explains the syntax and limitations.

Aptos does not have an exact equivalent, but it supports sponsored transactions where a third party pays the gas fee. Sui also supports sponsored transactions through its gas station pattern. The spoke page Aptos Sponsored Transactions How to Pay Gas for Your Users covers both chains and the risks of relying on a single sequencer for sponsored transactions.

Gas fees and storage

Gas calculation on Sui includes a storage fund component. When you create an object, you pay a storage fee that is held in the storage fund. When you delete the object, you receive a rebate. This incentivizes cleaning up unused state. The rebate does not always cover the full deletion cost - the spoke page Sui Gas Fees and Storage Fund How Transaction Costs Are Calculated explains the math.

Aptos uses a more traditional gas model where fees are based on computation and storage usage, with a minimum balance required for account creation. The spoke page covers both chains' approaches to fee calculation.

Module deployment and upgrades

Deploying a Move module on either chain requires understanding the upgrade policies. On Aptos, you can choose from several upgrade strategies: compatible, immutable, or only-additive. On Sui, upgrades are also possible but with different compatibility rules. The spoke page Aptos Move Module Upgrade Policies and Compatibility Rules covers both chains and explains the error PackageUpgradeError with incompatible module that you will see if you try to break storage compatibility.

An irreversible module upgrade can destroy storage compatibility, making existing data inaccessible. This is one of the most serious risks in Move development. The spoke page covers how to avoid it.

Debugging and Verification

MoveAbort Errors

When a Move transaction fails, it returns a MoveAbort with a location (module address and name) and an abort code. The abort code is a u64 that the developer defines. Reading it requires looking up the source code or the compiled bytecode. The spoke page MoveAbort Errors How to Debug and Handle Abort Codes on Sui and Aptos explains how to decode these errors using the CLI and block explorers.

Other common errors include OutOfGas during simulation (which tells you to increase the gas budget), ObjectOwnedByAnotherAddress on transfer (which means you tried to move an object you do not own), and SequenceNumberTooOld on concurrent account access (which means you sent two transactions from the same account too quickly). Each of these is documented in the error inventory.

Formal Verification with the Move Prover

The Move Prover is a formal verification tool that can prove properties about your smart contracts before deployment. It checks invariants like "this function never transfers more tokens than the sender owns" or "this module never aborts." The spoke page Move Prover How to Formally Verify Smart Contracts on Sui and Aptos walks through setting up the prover and writing specifications.

The prover is not a replacement for testing. It is a complement. It catches edge cases that tests miss, but it cannot prove everything. The spoke page explains the limitations.

Advanced Data Structures

Dynamic Fields and Object Nesting on Sui

Sui allows objects to contain dynamic fields - key-value pairs that can be added or removed after the object is created. This enables complex data structures like maps, sets, and trees without pre-allocating storage. The spoke page Sui Dynamic Fields and Object Nesting How to Build Complex Data Structures covers the API and the risks, including the error DynamicFieldNotFound when accessing child objects that have been deleted.

Tables and Objects on Aptos

Aptos provides the Table type for large collections, which stores data in a separate storage space to avoid bloating the account's state. The spoke page compares this to Sui's dynamic fields in the context of the Sui Object Ownership Types and Transfer Rules Every Developer Should Know spoke, which also explains the difference between immutable, shared, and owned objects.

The Decision Framework

If you are choosing between Sui and Aptos for a new project, the decision comes down to your data model requirements.

The spoke page Sui or Aptos Which Move Chain Should You Build On provides a detailed decision matrix with concrete examples.

Where to go next

You now have the map. Each of the following spoke pages answers one specific question completely. Choose the one that matches your current need:

Not financial advice. suiboxer.xyz publishes market data and general information about digital assets. Crypto assets are volatile and you can lose everything you put in. Nothing here is a recommendation to buy, sell or hold, and we make no price predictions.

Prices are sourced from third parties and may be delayed or wrong. Verify anything you intend to act on against a primary source.