Solana -> Sui
The biggest difference between Sui and Solana development lies in the programming language. Sui uses Move, while Solana relies on Rust, typically paired with a development framework that simplifies dApp development and management. Anchor is the most popular Solana framework.
| Topic | Rust (Solana) | Move (Sui) |
|---|---|---|
| Model | Account-based model where all data is stored in accounts. Programs declare read/write accounts upfront. Everything is an account (programs, data, wallets). | Object ownership inherent to Sui, objects are first class citizens and encompass everything owned on Sui. |
| Data storage | Data is stored in programs, stateless accounts that contain instructions. | Data is stored in Move objects. |
| Inheritance | No inheritance. Rust uses traits for shared behavior and composition over inheritance. | No interfaces, no polymorphism. However, Move has generics, like Type<T>. |
| Dynamic dispatch | Allowed through trait objects, but not commonly used in Solana programs due to performance overhead. | Not allowed |
| Asset and token accessibility | Tokens stored in Program Derived Addresses (PDAs). Access controlled through program logic and signer verification. | Anyone can access shared objects. Owned objects can only be accessed by the object owner. |
| Access control | Signer-based access control. Programs verify transaction signers and account ownership. PDAs enable program-controlled accounts. | Mostly capability based access control through owned objects. Identity and role-based access control is possible. |
| Contract upgrades | Programs can be marked as upgradeable or immutable at deployment. Upgrades replace the program binary but maintain the same program ID. | New contracts must be layout-compatible with the old one. You need to consider versioning shared objects. |
| Mutate contract state | Sending transactions with instruction data. Programs process instructions and modify account data. Can use Anchor's IDL (Interface Definition Language) for type-safe client interaction. | Sending transaction through runtime programmable transaction block (PTB) construction. |
| Type safety | Strongly typed at compile time with Rust's type system. Memory safety enforced by borrow checker. | Resource-oriented with linear types. Assets cannot be copied or dropped unless explicitly allowed. Strong type safety with Move Prover for formal verification. |
Object model
In Move, everything is an object. Objects serve as the fundamental data storage unit on Sui, containing Move packages (smart contracts), addresses, coins, NFTs, and all other on-chain data.
You can think of objects as assets with inherent ownership properties like NFTs, but generalized across all blockchain data. Every object has ownership.
Ownership
There are some nuances to object ownership, but key types include:
- Address-owned objects: These objects are owned by a single address. You can transfer or receive these objects without interacting with a smart contract. For example, currency, NFTs, or tokens gating access to certain functions.
- Shared objects: Publicly accessible objects that anyone can use. Mutating the data stored in these objects typically involves defining rules in the smart contract.
For all types of ownership on Sui, see Object Ownership.
Access control
Identity or role-based access control is widely used through OpenZeppelin's Ownable and AccessControl contracts in Solidity.
Because object ownership is inherent in Sui, access to contract functions is typically gated through capability objects.
These objects are issued to users and thus grant them the rights to call certain functions. Function calls fail if a user does not own the object a function expects.
You can still implement address-based checks. However, the recommendation is to use capability objects as much as possible for better security.
You can read more in The Move Book.
In this example, a new user can only be created by presenting an AdminCap object during the function call.
/// Grants the owner the right to create new users in the system.
public struct AdminCap {}
/// Creates a new user in the system. Requires the `AdminCap` capability to be
/// passed as the first argument.
public fun new(_: &AdminCap, ctx: &mut TxContext): User {
User { id: object::new(ctx) }
}
Mutating objects
In Rust, data structures are stored in separate account structures that programs read from and write to. Programs are stateless and declare which accounts they'll access upfront. Mutating data involves signing a transaction with the appropriate account references, and the program verifies signer permissions through explicit checks.
In Move, the logic that mutates the data is defined in the contract, but the data is stored in Move objects.
To mutate the data, the owner of the objects needs to call the contract functions using a PTB. The ownership check is done at a protocol level so transactions fail if the signer does not have access to the referenced objects.
Programmable transaction blocks
In Rust, if you want to chain together results of multiple program calls, you typically need to create multiple sequential transactions or use Cross-Program Invocations (CPIs) within a program. CPIs allow programs to call other programs atomically within a single transaction, but they're limited to 4 levels deep and require careful account management. Client-side transaction chaining lacks atomicity guarantees because each transaction must complete before the next can be submitted.
In Move, PTBs solve this problem. PTBs give builders the ability to chain contract calls together with atomicity guarantees during runtime. A Sui PTB can have up to 1,024 different contract calls in it, or other actions. PTBs effectively provide a limited scripting language that is straightforward yet expressive, powerful, and secure.
Builders on Sui leverage PTBs to provide experiences that would otherwise be intractable. A good example is a DeFi aggregator that routes token swaps across multiple DeFi protocols with the best price. On Sui, the aggregator would use a single PTB with the guarantee that the transaction would execute at the displayed price or it would revert completely. The PTB is one of the most powerful Sui features. Experience shows builders who are most successful on Sui are the ones who learn to leverage this feature early and often, leaning into it rather than treating it just as a way to batch transactions.
See Programmable Transaction Blocks for details on PTBs.
More comparison
| Topic | Solana | Sui |
|---|---|---|
| Digital signature algorithm | Ed25519 | Ed25519, secp256k1, secp256r1 |
| Consensus mechanism | Tower BFT (PoS variant) with Proof of History (PoH) | DPoS |
| VM and its languages | Solana VM, Rust, C, C++ | MoveVM, Move Lang |
| Chain data structure | Blocks with PoH ordering | DAG |
| Common standards (coin, token, NFT, and so on) | SPL Token, MPL Core, Token22 | Coin Standard, Closed-Loop Token |
| Coin names, name of the smallest unit | SOL, Lamport | SUI, MIST |
| Available frameworks for development | Anchor framework, Solana CLI, native Rust tooling | Sui CLI |
| L1 and L2 | Emerging but not widespread, mostly relies on fast L1 with parallel execution | No L2, relies on fast L1 with horizontal scaling |
| Governance | Off-chain governance through SIMD (Solana Improvement Documents) | On-chain governance |
| Bridges | Supported | Supported |
| Network security (stake required for control) | 66% of total stake (BFT requirement) | 66% of total stake |
| Smart contract auditing | Requires comprehensive auditing due to account model complexity, PDA patterns, and CPI vulnerabilities | Less auditing required, language does some of the lifting (object model) |
| Private transactions | Public by design | Public by design |
| TVL (as of late 2025) | ~10 billion | ~2.6 billion |
| Implementation languages for clients | Rust, TypeScript (web3.js, @solana/kit), Python, Go | Rust, TypeScript, Python |
| Eventing | Indexed by program logs, requires custom parsing or indexer | Indexed by sender, object ID, type, timestamp |
| Indexing | High level transaction data, requires custom indexers (Helius, Triton, Shyft) | High level transaction data + objects, coins, GraphQL RPC support |
| Oracles | Third party | Third party |
| Network upgrade strategy | Feature gates voted on by validators, activated when supermajority is reached | Protocol flags and framework upgrades voted on by validators then enabled |
| IDE | VSCode (Rust Analyzer) | VSCode (Move extension) |
| Transaction lifecycle | Transaction submitted to RPC, gossipped to leaders, included in block, voted on by validators using Tower BFT. | Two round trips from client to validators to generate transaction certificate (guaranteeing execution), another round trip for shared objects to ensure ordering. |
| Parallel execution | Sealevel runtime enables parallel execution when transactions don't overlap in account access. Accounts must be declared upfront for scheduling. | Transactions that can be parallel are run in parallel. |
| Storage fees, storage rebates | Rent-exempt accounts require minimum balance. No rent collection since 2021, no rebates. | Low storage fees paid upfront, rebates on destroying objects to incentivize cleanup. |
| Contract immutability | Programs can be marked upgradeable or immutable at deployment time. | Native mutable and immutable support using upgrade capabilities as objects. |
| Contract upgrading | Native, programs marked as upgradeable can be upgraded by the upgrade authority. | Native, upgrade capability mediated. |
| Composability | Cross-Program Invocations (CPIs) allow programs to call other programs within a transaction. Limited to 4 levels deep. Atomic within transaction boundaries. | Call any number of functions within a single transaction using PTBs. Compose by taking output of one call and passing into another. Ensures atomic execution with up to 1,024 commands per PTB. |
| Token royalties | Not directly. Enforced through protocols like MPL Core, or extensions like Token22. | Enforced by the chain through Kiosk and transfer policies. |
| Block time and finality | ~400ms block time, ~12-13 seconds for economic finality (before Alpenglow upgrade). | Sub-second finality for independent transactions, ~390ms with Mysticeti for shared objects. |
Related links
Move is an open source language for writing safe packages to manipulate on-chain objects.
On Sui, object ownership can be represented in different ways. Weigh the benefits of each to decide the best approach for your project.
Programmable transaction blocks are a group of commands that complete a transaction on Sui.
Learn more about Dynamic Object Fields in The Move Book.