Sui and Solana: parallel execution, accounts, and fees

Sui and Solana can support the same user goal, such as sending a token or calling a DeFi application, but the wallet prepares different state descriptions for each chain. The important comparison is what a transaction declares, which state it can change, and how the fee is assembled.

Solana declares accounts and locks

Solana's account documentation describes state as accounts keyed by 32-byte addresses. Each account has lamports, data, an owner program, executable status, and a rent field. A Solana instruction includes a program ID, data, and an ordered account list. For every account in that list, the transaction declares whether it is writable or read-only and whether the signer authorizes the action.

Those declarations are execution inputs. A program can read a read-only account, while a writable account may be changed under the runtime's ownership rules. The validator can use the declared access set to find transactions that do not contend on the same writable accounts. That is the basis for parallel scheduling: independent account sets can run together, while transactions that need the same write lock must wait or be ordered.

The Solana transaction guide adds signatures, a recent blockhash, and compiled instructions. The transaction executes atomically, so a failed instruction does not leave its state changes applied, but the fee rules can still charge the attempt.

Solana has base and priority fee layers

Solana's fee structure separates a base fee from an optional prioritization fee. The base fee is calculated from signatures. The priority fee is based on the requested compute-unit limit and price, and it can help a transaction compete for block space. A wallet may therefore show both ordinary signature cost and a priority setting. A higher priority setting is an execution-order choice, not evidence that the transaction is safer or more likely to succeed.

Sui names objects and transaction inputs

Sui uses a different review vocabulary. Its object model gives objects stable IDs, versions, and ownership. An owned object can generally be processed without contending on a shared object; a shared object is an explicit shared input whose access is coordinated by the network. A Sui programmable transaction block (PTB) then composes commands over those inputs and can pass one command's output to the next.

The distinction is practical. On Solana, a swap prompt may list a program, a token mint, a fee payer, and several accounts with read/write flags. On Sui, the prompt and transaction data may identify coin or other object inputs, shared pools, commands, gas, and output conditions. “Owner” also means different things: Solana's account owner is the program permitted to modify data, while Sui object ownership identifies the address or sharing rule that controls the object input.

Review one identical task

Imagine sending 5 units of a token to a recipient. On Solana, verify the exact mint, recipient account, fee payer, program instructions, recent blockhash, writable accounts, and base or priority fee. On Sui, verify the full coin type, owned coin or address balance, recipient, PTB commands, gas budget, and any shared object such as a pool. A ticker and an address fragment are insufficient on either network.

The resulting records are chain-specific. A Solana signature and transaction details prove what Solana accepted. A Sui digest and effects prove what Sui accepted. Do not transfer assumptions about account lists, object versions, priority fees, or application indexing between them. Compare the exact transaction at the layer where the wallet asks you to sign.

Further reading: Sui object ownership, Sui gas budgets, and Sui versus Ethereum account state.