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 app development and management. Anchor is the most popular Solana framework.
| Topic | Rust (Solana) | Move (Sui) |
|---|---|---|
| Model | Account-based model where accounts store all data. 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 | Programs, stateless accounts that contain instructions, store data. | Move objects store data. |
| 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. Only the object owner can access owned objects. |
| 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 | You can mark programs as upgradeable or immutable at deployment. Upgrades replace the program binary but keep 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. The borrow checker enforces memory safety. | Resource-oriented with linear types. You cannot copy or drop assets unless their type explicitly allows it. 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 onchain 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: A single address owns these objects. 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
On Solana, access control is typically signer-based: programs verify transaction signers and account ownership, and Program Derived Addresses (PDAs) enable program-controlled accounts.
Because object ownership is inherent in Sui, you typically gate access to contract functions through capability objects.
You issue these objects to users, granting 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, only a caller who presents an AdminCap object during the function call can create a new user.
/// Grants the owner the right to create new users in the system.
public struct AdminCap has key { id: UID }
/// 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) }
}
How do I mutate objects on Sui?
In Rust, separate account structures store data structures, and programs read from and write to them. Programs are stateless and declare which accounts they 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 contract defines the logic that mutates the data, but Move objects store the data.
To mutate the data, the owner of the objects calls the contract functions using a PTB. The protocol checks ownership at the 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 are limited to 4 levels deep and require careful account management. Client-side transaction chaining lacks atomicity guarantees because each transaction is independent and a failure in one does not revert the others.
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 uses a single PTB with the guarantee that the transaction executes at the displayed price or reverts 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 Building Programmable Transaction Blocks for the full guide on constructing PTBs with the TypeScript SDK, including moveCall, chaining results, and gas management.
How else does Sui compare to Solana?
| Topic | Solana | Sui |
|---|---|---|
| Digital signature algorithm | Ed25519 | Ed25519, secp256k1, secp256r1 |
| Consensus mechanism | Tower BFT (PoS variant) with Proof of History (PoH) | DAG-based BFT consensus (Mysticeti), with validators selected by 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 | Offchain governance through SIMD (Solana Improvement Documents) | Onchain 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 | Auditing still required. The language and object model do some of the lifting, which can reduce the auditing burden |
| 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 | Validators vote on feature gates, which activate when a supermajority approves them | Protocol flags and framework upgrades voted on by validators then enabled |
| IDE | VSCode (Rust Analyzer) | VSCode (Move extension) |
| Transaction lifecycle | Transaction submitted to RPC, gossiped to leaders, included in block, voted on by validators using Tower BFT. | The client submits the transaction to a full node, which forwards it to a validator through Transaction Driver. Validators vote on it, consensus commits it in a block, and every validator executes it against the same ordered state. Low latency. |
| Parallel execution | Sealevel runtime enables parallel execution when transactions don't overlap in account access. Transactions must declare accounts upfront for scheduling. | Sui runs transactions in parallel when they can 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 | You can mark programs as upgradeable or immutable at deployment time. | Native mutable and immutable support using upgrade capabilities as objects. |
| Contract upgrading | Native, the upgrade authority can upgrade programs marked as upgradeable. | 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 enforced 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. |
What should I read next?
- Learn the Move concepts Sui uses: Move.
- Learn the types of object ownership: Object Ownership.
- Learn capability-based access control: The Move Book.
- Learn how PTBs work: programmable transaction blocks, then Building Programmable Transaction Blocks.
- Before you upgrade a package, review the upgrade requirements.