Skip to content
DeFi Reference

Accounts and execution models

1. TL;DR

Section titled “1. TL;DR”

Ethereum stores state inside accounts that carry their own code and storage, and executes each block’s transactions one after another because the EVM only discovers which state a transaction touches while running it. Solana separates code (stateless programs) from data (accounts that programs own), and every transaction declares up front which accounts it will read or write, so non-overlapping transactions run in parallel. Both give a single transaction atomic composability, but Ethereum has pushed most activity to rollups with separate state, while Solana keeps one shared state machine and pays with account contention.

2. Explain it simply

Section titled “2. Explain it simply”

Analogy

Section titled “Analogy”

Picture two government offices. In the Ethereum office there is one clerk and one queue; each citizen’s folder holds both their paperwork and the rulebook for handling it, and the clerk opens folders one by one, discovering as they go which other folders the case touches. In the Solana office every citizen writes on their ticket the exact folders their case needs before joining the line; tickets with no overlapping folders go to different clerks working simultaneously, and only tickets that share a folder wait for each other. Solana’s office moves more cases per hour, but one popular folder (a hot token launch) still queues at a single clerk.

ELI5

Section titled “ELI5”

A blockchain is a giant shared notebook. On Ethereum every page belongs to a program that stores its own numbers on that page, and the computer reads the pages in strict order, one transaction at a time. On Solana the programs are just recipe cards with no numbers on them; the numbers live in separate pages called accounts, and each transaction has to say in advance which pages it will touch. Because the computer knows the page list ahead of time, it can process many transactions at once as long as they do not touch the same page. If everybody wants the same page at once, they still have to wait their turn.

Step-by-step walkthrough

Section titled “Step-by-step walkthrough”

One block contains three transactions: (1) Alice sends 10 USDC to Bob, (2) Carol sends 5 USDC to Dave, (3) Eve swaps 1 ETH/SOL for USDC on a DEX pool.

  1. Before. Alice holds 100 USDC and Bob 0; Carol holds 50 and Dave 0; the pool holds 1,000 USDC. Alice’s account nonce is 7 (Ethereum) or her USDC token account has balance 100 (Solana).
  2. Ethereum execution. The EVM runs tx 1, then tx 2, then tx 3, in the builder’s order. Tx 1 calls the USDC contract, which sets balances[Alice] 100 → 90 and balances[Bob] 0 → 10 in its storage trie; Alice’s nonce becomes 8 and she pays gas. Tx 2 waits for tx 1 even though it touches different slots, because the runtime never learned the read-write sets in advance.
  3. Solana execution. Each transaction lists its accounts with read/write flags: tx 1 write-locks Alice’s and Bob’s token accounts, tx 2 Carol’s and Dave’s, tx 3 the pool vaults and Eve’s accounts. No locks overlap, so all three execute on different threads at once. Alice’s token account goes 100 → 90 and Bob’s 0 → 10; if Bob had no USDC account, the same transaction creates it and Alice pays its storage deposit.
  4. After. Final balances are identical on both chains: Alice 90, Bob 10, Carol 45, Dave 5, pool 1,000 minus Eve’s output. The difference is how long the block took to execute and what each user paid. Had a fourth transaction also written Bob’s account, Solana would have serialised it behind Alice’s while the other two still ran in parallel.

Common misconceptions

Section titled “Common misconceptions”
  • Myth: “Solana programs store data like Ethereum contracts.” Reality: Programs are stateless; mutable state lives in separate accounts only the owner program may modify (Solana docs).
  • Myth: “Solana is parallel, so it never queues.” Reality: Writes to the same account are serialised; Solana’s longest conflict chains average about 58% of a block versus about 18% on Ethereum (Anjana, Ravi and Herlihy, 2025/2026).
  • Myth: “Every address has a private key.” Reality: Ethereum contract accounts and Solana program derived addresses are both keyless; the latter are deliberately off the Ed25519 curve.
  • Myth: “The EVM can never execute in parallel.” Reality: It is read-write-oblivious, so parallelism needs optimistic execution or access lists, which Glamsterdam’s block-level access lists target (ethereum.org roadmap, accessed 2026-08).

If you only remember one thing

Section titled “If you only remember one thing”

Ethereum learns what a transaction touches by running it; Solana is told in advance, and that one design choice explains most of the differences in parallelism, fees and developer ergonomics.

3. How it works

Section titled “3. How it works”

Ethereum: accounts, contracts, sequential execution

Section titled “Ethereum: accounts, contracts, sequential execution”

Every Ethereum account is a four-field record in the world-state trie: a nonce (transactions sent by an externally owned account, or contracts created by a contract account), a balance in wei, a codeHash (hash of the empty string for an externally owned account) and a storageRoot, “a 256-bit hash of the root node of a Merkle Patricia Trie that encodes the storage contents of the account” (ethereum.org, Accounts, accessed 2026-08). There are two kinds: externally owned accounts (EOAs), “controlled by anyone with the private keys”, and contract accounts, “a smart contract deployed to the network, controlled by code”. An EOA address is the last 20 bytes of the Keccak-256 hash of the public key; a contract address comes from the creator’s address and nonce, or from a salt and the creation code under CREATE2. Since Pectra (2025-05-07) an EOA can also “set their address to be represented by a code of an existing smart contract” (EIP-7702; ethereum.org roadmap, accessed 2026-08).

Execution is single-threaded: transactions are applied in the block’s order, with state accesses discovered at run time. Anjana, Ravi and Herlihy call this the read-write-oblivious model: before execution the executor “has no sound over-approximation of the read and write sets of individual transactions”, so it can parallelise only optimistically, executing speculatively and validating that the result equals the sequential one. The theoretical ceiling on parallel speedup for any block is set by the longest conflict chain LL (the critical path of transactions that must run one after another):

Smax⁡  =  nLS_{\max} \;=\; \frac{n}{L}

where nn is the number of transactions in the block. Their historical measurements (arXiv 2505.05358, v3 2026-05) show that in each historical period over 50% of Ethereum blocks contained more than 50% independent transactions, with the conflict chain about 16% of block size on average across periods and about 6.9% in a recent sample of blocks 21631001–21631020.

Solana: accounts, programs, PDAs, CPIs

Section titled “Solana: accounts, programs, PDAs, CPIs”

Solana’s state is “a key-value store where each key is a 32-byte address and each value is an account” (Solana docs, Accounts). Every account has the same five fields: lamports, data, owner, executable and rent_epoch. The ownership rule is the security primitive: “Only the account’s owner program can modify its data or debit lamports. Any program can credit lamports to any writable account.” Accounts must hold a refundable minimum balance proportional to their size,

min_balance=(account_size+128)×3,480 lamports/byte-year×2 years,\text{min\_balance} = (\text{account\_size} + 128)\times 3{,}480\ \text{lamports/byte-year}\times 2\ \text{years},

(Solana docs, as of 2026-08). A program is an account whose executable flag is true and whose data is sBPF bytecode; programs are stateless and upgradeable until the upgrade authority is revoked.

A program derived address (PDA) is a 32-byte address derived from a program ID plus up to 16 seeds (each at most 32 bytes) and a one-byte bump; the derivation is retried with a different bump until the result is off the Ed25519 curve, so “no private key exists for them” and only the deriving program can sign for the PDA through invoke_signed. This gives deterministic per-user storage (e.g. the associated token account from [wallet, mint]) and lets programs act as custodians.

A cross-program invocation (CPI) is one program calling an instruction on another. Privileges (signer, writable) extend from caller to callee and can never be escalated; the instruction stack is limited to 5 deep (9 with SIMD-0268); direct self-recursion is allowed but indirect reentrancy (A → B → A) is rejected with ReentrancyNotAllowed (Solana docs, CPI, as of 2026-08).

A transaction bundles instructions, signatures and a recent blockhash (valid 150 slots); all instructions succeed or all revert, and fees are charged on failure. The message is limited to 1,232 bytes and 64 account addresses (a coming v1 format raises the size to 4,096 bytes). Each instruction “explicitly defines which accounts it can access and the permissions required for each” (Helius). This is the read-write-aware model: the runtime takes write locks on declared accounts in the banking stage, so “transactions accessing read-only accounts are executed in parallel. In contrast, transactions accessing overlapping writable accounts are serialized” (Helius). The bound Smax⁡=n/LS_{\max}=n/L still applies, and because hot accounts (pools, mints, oracles) concentrate writes, Solana’s measured conflict chains are long: about 58% of a block versus about 18% on Ethereum (arXiv 2505.05358).

Atomic composability and fragmentation

Section titled “Atomic composability and fragmentation”

On both chains a single transaction can call many contracts atomically; the difference is where state lives. Ethereum’s rollup-centric roadmap moved execution to L2s, each with its own state and sequencer: L2s collectively process about 5x mainnet’s transactions while their bridges occupy under 2% of Ethereum state (Paradigm, as of 2024-03), and cross-rollup calls are not atomic (see /cross-chain/cross-l2-interop/). Solana’s goal is “a scalable unified base layer where all applications coexist seamlessly” (Helius, Local Fee Markets), which keeps composability but imports contention; Helius describes this as choosing vertical scaling and hitting “some sort of horizontal scaling threshold due to the global single-sharded state model”.

4. Worked numeric example

Section titled “4. Worked numeric example”

Same block as §2: Alice → Bob 10 USDC, Carol → Dave 5 USDC, Eve swaps on a pool.

Solana costs and state. Each transfer has one signature, so the base fee is 5,000 lamports (0.000005 SOL), 50% burned and 50% to the leader (Solana docs, Fees, as of 2026-08); an SPL Token transfer uses about 4,645 compute units on the legacy program and 249 under P-Token (Solana Foundation, 2025-08). With no priority fee, Alice pays 5,000 lamports. If Bob has no USDC account, her transaction creates one of 165 bytes, whose minimum balance is (165+128)×3,480×2=2,039,280(165+128)\times 3{,}480\times 2 = 2{,}039{,}280 lamports (about 0.00204 SOL), refundable when the account is closed. State: Alice’s token account 100 → 90 USDC, Bob’s 0 → 10; lamports: Alice −0.000005 SOL fee −0.00204 SOL deposit.

Ethereum costs and state. A plain ETH transfer has an intrinsic cost of 21,000 gas (Paradigm, Analysis of EIP-1559, 2020-06); a token transfer costs more because it runs contract code. At an illustrative base fee of 10 gwei and 1 gwei tip, 21,000 gas costs 21,000×11 gwei=0.00023121{,}000\times 11\ \text{gwei} = 0.000231 ETH, of which the base-fee part is burned. State: balances[Alice] 100 → 90, balances[Bob] 0 → 10 in the USDC contract’s storage trie; Alice’s nonce 7 → 8 (fee formulas in /foundations/fee-markets/).

Parallelism bound. Three transactions with disjoint write sets give L=1L=1, so Smax⁡=3S_{\max}=3 on Solana; on Ethereum they run sequentially regardless. A fourth transaction writing Bob’s account makes L=2L=2 and Smax⁡=2S_{\max}=2. At the arXiv sample’s scale, a recent Ethereum block of n=176n=176 with a 6.92%6.92\% conflict chain has L≈12L\approx 12 and Smax⁡≈14.5S_{\max}\approx 14.5 if the EVM were parallelised; a Solana block whose chain is 58%58\% of the block has Smax⁡≈1.7S_{\max}\approx 1.7 on the critical path, so Solana’s gains come from the independent transactions outside the chain.

5. Where it’s used

Section titled “5. Where it’s used”

Ethereum

Section titled “Ethereum”
  • Uniswap pools — each pool is a contract whose storage trie holds reserves and positions, updated sequentially by every swap in a block — /exchange/cfmm-math/.
  • EIP-7702 / ERC-4337 — let an EOA delegate to contract code for batching and sponsorship (Paradigm, 2025-01) — /foundations/roadmaps/.
  • Rollups — per-L2 state; bridges hold under 2% of L1 state while L2s process about 5x mainnet’s transactions (Paradigm, 2024-03) — /cross-chain/bridge-designs/.

Solana

Section titled “Solana”
  • Associated Token Account program — each wallet’s balance of each token is a PDA seeded by [wallet, mint], “a canonical place to look up a user’s holdings” that can be updated in parallel (Helius, PDAs) — /foundations/token-standards/.
  • Config and vault PDAs — programs keep admin config in a "config" PDA and let PDAs own token accounts and sign via invoke_signed (Helius, PDAs).
  • Jito bundles and local fee markets — both exploit declared account lists: Jito auctions non-intersecting bundles separately and priority fees are effectively per-account (Jito docs; Helius) — /mev/solana-mev/.

6. Risks, attacks, and incidents

Section titled “6. Risks, attacks, and incidents”
  • Unsafe external calls / reentrancy (Ethereum). The DAO drained “over 3.6 million ETH” in 2016, leading to the 2016-07-20 hard fork and the Ethereum Classic split (ethereum.org, History); samczsun shows the class recurring through ERC-777/1155 callbacks (Paradigm, 2021-08).
  • Missing account validation (Solana). Wormhole, 2022-02-03: 120,000 ETH (about $326M) minted after verify_signatures accepted a fake sysvar account because “the contract didn’t correctly verify the address being provided”; Cashio, 2022-03-23: about $48M minted because “the .mint field is never validated” (both rekt.news, secondary). Helius’ security guide lists missing signer/owner checks, account reinitialisation, PDA seed collisions and overflow as recurring vectors.
  • Hot-account contention and spam. NFT mints in 2021–2022 “caused Solana to temporarily halt block production” (Helius, Solana MEV introduction); in April 2024, 75.7% of non-vote transactions reverted (Helius, Local Fee Markets, as of 2025-01).

7. Open problems

Section titled “7. Open problems”
  • How much EVM parallelism is real? Anjana et al. conclude that “no single parallel execution strategy” fits all periods because conflict structure shifts with hot contracts; Glamsterdam’s block-level access lists are Ethereum’s next step (ethereum.org roadmap, accessed 2026-08).
  • Multiple concurrent leaders on Solana. How to partition write sets so two leaders never lock the same account, merge per-lane certificates and price fees across lanes is unanswered (Helius, Alpenglow, 2025).
  • Account limits. The 64-account cap (128 behind an inactive feature gate) and 1,232-byte messages constrain composable transactions; the v1 format raises size to 4,096 bytes (Solana docs, as of 2026-08).
  • Single state machine vs fragmentation. Whether unified state (Solana) or rollup fragmentation (Ethereum) wins is contested; Paradigm’s “L1 Dilemma” (2025-06) frames it as incumbent dogma versus specialised newcomers.

8. Ethereum vs Solana

Section titled “8. Ethereum vs Solana”
AspectEthereumSolana
Account recordnonce, balance, codeHash, storageRootlamports, data, owner, executable, rent_epoch
Code and stateContract holds its own storage triePrograms stateless; data in owned accounts
Keyless addressesContract addresses (CREATE/CREATE2)PDAs (off-curve, seeds + bump)
Access declarationDiscovered at run time (read-write-oblivious)Declared per instruction (read-write-aware)
ExecutionSequential per blockParallel across non-conflicting write sets
Cross-contract callCALL; reentrancy allowedCPI; depth 5 (9 w/ SIMD-0268); indirect reentrancy rejected
Tx limitsGas limit per block (~60M, Fusaka)1,232 bytes, 64 accounts, 1.4M CU
Composability scopeL1 atomic; L2s fragmentedSingle global state machine

Ethereum keeps transactions opaque and pays with sequential execution; Solana makes developers enumerate accounts and pays with contention on popular state, which is what local fee markets and Jito’s lock-aware auctions try to price.

9. Reference doc

Section titled “9. Reference doc”

The reference

Section titled “The reference”

Solana Account Model (Core Concepts: Accounts, Programs, PDAs, CPI) — Solana Foundation documentation, as of 2026-08. https://solana.com/docs/core/accounts

Summary of the reference

Section titled “Summary of the reference”

The Solana core-concepts pages describe the account model from the storage layer up. The Accounts page starts with the key-value definition: a 32-byte address maps to an account with five fields (lamports, data, owner, executable, rent_epoch), and it states the two invariants that everything else depends on, namely that only the owner program can modify data or debit lamports, and that every account must hold a refundable minimum balance proportional to its size. A limits table pins the constants: 10 MiB max data, 10 KiB growth per instruction, 64 bytes base overhead, and the formula (size+128)×3,480×2(\text{size}+128)\times 3{,}480\times 2 lamports for the minimum balance.

The Programs page defines a program as an executable account containing sBPF bytecode, stresses that programs are stateless and that mutable state lives in separate accounts, and explains upgradeability via loader-v3 (immutability once the upgrade authority is revoked). Its limits table includes heap (32 KiB default, 256 KiB max), 64-deep sBPF call depth, and an instruction stack depth of 5 (9 with SIMD-0268).

The PDA page explains derivation from a program ID and up to 16 seeds plus a bump, the off-curve guarantee, and why this matters: deterministic addressing, program signing through invoke_signed, user-scoped state, and no key management. It gives compute costs (1,500 CU per create_program_address attempt).

The CPI page describes invoke versus invoke_signed (the latter adds PDA seeds to the signer set), privilege extension without escalation, the shared compute budget, the reentrancy rule (direct recursion allowed, indirect rejected), and limits such as 10 KiB instruction data, 1,024 bytes of return data and 128 account infos (255 with SIMD-0339).

The Transactions and Fees pages complete the picture: transactions are atomic, at most 1,232 bytes with 64 accounts and a 150-slot blockhash window; the base fee is 5,000 lamports per signature split 50/50 burn/validator, and the prioritisation fee is ⌈cu_price×cu_limit/106⌉\lceil \text{cu\_price}\times\text{cu\_limit}/10^6\rceil lamports, 100% to the validator.

Key quotes

Section titled “Key quotes”

“An account is Solana’s fundamental data unit for storing state. The network stores all state in a key-value store where each key is a 32-byte address and each value is an account.” — Accounts, opening paragraph “Only the account’s owner program can modify its data or debit lamports. Any program can credit lamports to any writable account.” — Accounts, Key facts “Programs are stateless. All mutable state lives in separate data accounts passed via instructions.” — Programs, opening paragraph “They are guaranteed to not lie on the Ed25519 curve, which means no private key exists for them.” — PDAs, opening paragraph “Direct self-recursion is allowed (A->A->A). Indirect reentrancy is not (A->B->A returns ReentrancyNotAllowed).” — CPI, Key facts

How to read the original

Section titled “How to read the original”

Background needed: public-key cryptography basics, the idea of a state machine, and (for the CPI page) what a call stack is. Read Accounts → Programs → PDAs → CPI in that order; skip the limits tables and the Anchor code samples on a first pass and return to them when writing a program. The hardest paragraph is the PDA off-curve guarantee: an Ed25519 public key is a point on a curve, so a 32-byte string that is not a valid point can never have a matching private key; the runtime therefore lets the program that derived the address “sign” for it by supplying the seeds, which only that program ID could have produced.

What changed since

Section titled “What changed since”

Feature gates keep moving the constants: SIMD-0268 raises instruction stack depth from 5 to 9, SIMD-0339 lowers CPI cost to 946 CU and raises account infos to 255, the transaction account limit of 128 remains behind an inactive gate, and the v1 message format will raise messages to 4,096 bytes with an absolute-lamport priority fee (all as of 2026-08). P-Token cut the Token program’s transfer cost from about 4,645 to 249 CU (Solana Foundation, 2025-08). Alpenglow (SIMD-0326, approved 2025-09) changes consensus but not the account model.

Secondary references

Section titled “Secondary references”
  1. Anjana, Ravi, Herlihy — “Blockchain Transaction Conflicts: A Historical Perspective” (arXiv 2505.05358, 2025-05, v3 2026-05) — read if you want measured conflict data for both chains (second reference below).
  2. ethereum.org — “Ethereum accounts” (accessed 2026-08) — read if you need the EVM account fields and address derivation.
  3. Helius — “At The Edge Of Determinism: Transaction Lifecycle in Solana Sealevel and Sui Object Runtime” — read if you want the TPU/banking-stage pipeline in prose.
  4. Helius — “What are Solana PDAs? Explanation & Examples” — read if PDAs still feel abstract; four worked examples.
  5. Helius — “A Hitchhiker’s Guide to Solana Program Security” — read if you are about to write or audit a program.

The reference

Section titled “The reference”

Blockchain Transaction Conflicts: A Historical Perspective — Parwat Singh Anjana, Srivatsan Ravi, Maurice Herlihy; arXiv 2505.05358, 2025-05-08 (v3 2026-05-13). https://arxiv.org/abs/2505.05358

Summary of the reference

Section titled “Summary of the reference”

The paper measures how much parallelism historical Ethereum and Solana blocks actually contain. Section I frames the question: any VM receives a block with a preset order T1→⋯→TnT_1 \to \dots \to T_n and must produce the sequential result; conflicting transactions must respect the order, independent ones may run anywhere. Section II formalises two executor classes. A read-write-oblivious executor (the EVM) discovers read and write sets during execution and must therefore use optimistic execution or static analysis; a read-write-aware executor (Solana’s Sealevel) receives declared account lists and read/write modes and can schedule conflicts up front. Two transactions conflict when TiT_i precedes TjT_j and (Wi∩Wj)∪(Wi∩Rj)∪(Ri∩Wj)≠∅(W_i\cap W_j)\cup(W_i\cap R_j)\cup(R_i\cap W_j)\neq\emptyset. The metrics are the percentage of independent transactions, the number of conflicts and conflict families, and the longest conflict chain (LCC), which bounds speedup by n/LCCn/\text{LCC}.

Section III describes data extraction across historical periods (HPs) for both chains, including congestion episodes. Section IV reports Ethereum results: in every period more than half of blocks have over 50% independent transactions, conflict chains average about 16% of block size, and recent blocks 21631001–21631020 average 176 transactions with 66.17% independent and a chain of 6.92%; access skew concentrates on a few EOAs and contracts. Section V reports Solana: blocks are larger and chains longer, about 58% of the block on average, driven by hot accounts. The takeaway is that no single parallel strategy is optimal across periods and that access locality, not raw block size, predicts achievable speedup.

Key quotes

Section titled “Key quotes”

“state access patterns become known only at execution time, a strategy we call the read-write-oblivious model. By contrast, Solana requires clients to pre-declare state access patterns, a strategy we call the read-write-aware model.” — Section I “historical Ethereum blocks frequently achieve high independence, with over 50% independent transactions in more than 50% of blocks, while, on average, Solana blocks contain longer conflict chains ∼58%, compared to ∼18% in Ethereum” — Abstract “The longer the chain, the lower the speedup.” — Section II, definition of the longest conflict chain

How to read the original

Section titled “How to read the original”

You need basic set notation and the idea of a critical path from scheduling theory. Read the abstract, Section II definitions and the two “Takeaway” paragraphs first; skip the per-block tables on the first pass. The hardest part is Definition 2’s “preset serializable” requirement: parallel execution is only allowed if the final state equals the one from executing the block in its given order, which is why the LCC (not the number of conflicts) is the binding constraint.

What changed since

Section titled “What changed since”

The v3 revision (2026-05) added recent block samples. Ethereum’s Glamsterdam upgrade (planned Q4 2026) targets block-level access lists, which would move the EVM toward the read-write-aware model (ethereum.org roadmap, accessed 2026-08). Solana’s Agave central scheduler (v1.18, 2024-05) builds a prio-graph of conflicting transactions, the practical implementation of conflict-aware scheduling the paper analyses (Helius, Local Fee Markets).

Secondary references

Section titled “Secondary references”
  1. Helius — “Sealevel vs Sui transaction lifecycle” — read if you want to see where account locking happens in the banking stage.
  2. Helius — “The Truth about Solana Local Fee Markets” — read if you want the scheduler’s priority formula and the prio-graph.
  3. Paradigm — “How to Raise the Gas Limit, Part 1: State Growth” (2024-03) — read if you want the state-size numbers behind Ethereum’s scaling debate.

10. Sources

Section titled “10. Sources”