Sui Move for EVM and SVM Developers: Part 1 - Mental Models
Switching ecosystems isn't about learning new syntax - it's about unlearning assumptions. A DEX or lending market still follows familiar logic, but the way you manage state, enforce permissions, and process transactions varies across architectures. In this post, we compare how EVM, Solana, and Sui handle core contract operations (focusing on mental models, not language syntax), so you can build in Move with the right design instincts from the start.
Mental Models: From Storage to Objects
EVM: Monolithic Contract Storage
EVM treats each smart contract like a mini-computer with its own storage space. When you deploy a contract, all your state variables, mappings, balances, and arrays get packed into sequential 256-bit slots within that contract's address. Everything lives together in one place, which makes it straightforward to reason about but can get messy when contracts become large and complex.
It's the most familiar model for developers coming from traditional programming, where you'd naturally group related data and functions into a single class or module.
SVM: The Account-Based Architecture
Solana operates on the principle that everything is an account: programs, data, even the system itself. Smart contract code lives in program accounts, user balances live in token accounts, and any persistent data gets stored in dedicated data accounts.
This means you can't just declare a variable and expect it to persist - you need to design account structures to hold your data and explicitly manage which accounts your program interacts with. The benefit is massive parallelization since the runtime knows exactly which accounts each transaction will touch.
Sui Move: The Object-Centric Model
Sui treats everything as objects with unique IDs and clear ownership rules - coins, NFTs, smart contracts, and system resources all exist as individual objects rather than data stored within contracts or accounts.
Unlike other blockchains where logic and data are bundled together, Sui separates code (module objects) from data (instance objects). Your coin balance exists as a standalone object that references shared module objects for its behavior. When you transfer value or update state, you're literally moving or modifying these objects.
Simple operations like token transfers can bypass validator consensus entirely since they only affect single-owner objects. This object-centric model makes composability natural since objects can contain other objects or references, but requires rethinking application architecture around ownership patterns and object interactions.
Basic Operations Across Ecosystems
Native Token Transfers
Ethereum: Native ETH transfers work through direct balance updates in the global blockchain state. When Alice sends 1 ETH to Bob, the EVM decrements Alice's account balance and increments Bob's account balance atomically. Both balances are stored in the global state trie, which means every ETH transfer requires a world state update and full validator consensus.
Solana: Native SOL transfers are handled by the System Program. When Alice sends 1 SOL to Bob, she creates a transaction containing a system_instruction::transfer that invokes the System Program. The System Program decrements lamports from Alice's account and adds them to Bob's. This account-based approach allows Solana to process multiple non-conflicting transfers in parallel.
Sui: Native SUI transfers work through object manipulation rather than balance updates. When Alice sends 1 SUI to Bob, her existing Coin object is split into two separate objects: one remains with Alice containing the remaining balance, and a new Coin object is created containing the transfer amount. Since each Coin object has a unique ID and clear ownership, simple transfers don't require consensus from validators.
Access Control
Ethereum: EVM handles access control through function modifiers and runtime validation using the caller's address (msg.sender). If the caller doesn't have the required permissions, the require() statement fails and the entire transaction reverts.
Solana: Access control is enforced through account ownership and PDA (Program Derived Address) verification. Programs check that the correct authority has signed the transaction, and PDAs ensure that only the originating program can modify certain accounts.
Sui Move: Access control in Sui is enforced through capability objects. Instead of checking msg.sender, you pass a capability object that proves you have the right to perform an action. This makes permissions tangible - you can transfer, split, or destroy capabilities, and the language's type system enforces these rules at compile time.
State Management
Ethereum: State is persistent by default. Variables declared at the contract level are automatically stored and retrieved between transactions.
Solana: State must be explicitly managed through accounts. You define account structures, allocate space, and serialize/deserialize data manually (or via frameworks like Anchor).
Sui: State lives in objects. Each object has a clear owner (an address, another object, or shared). Shared objects require consensus, while owned objects can be modified in parallel. This ownership model is the key mental shift when coming from other ecosystems.
Key Takeaways
- EVM → contract-centric, global state, address-based permissions
- SVM → account-centric, explicit data management, signature-based permissions
- Sui Move → object-centric, ownership-based state, capability-based permissions
The Sui model requires the most mental shift, but it's also the most expressive for complex ownership patterns. In Part 2, we'll look at how these mental models translate to practical code patterns for common DeFi use cases.