What is Account Model?

Introduction

The account model is a way for a blockchain to represent who owns what and how state changes over time. Instead of treating coins as separate chunks that are individually spent and recreated, the ledger keeps a persistent state for each address or account: a balance, some metadata, and, on programmable chains, often code and storage as well. That design sounds natural because it resembles a bank ledger or an application database. But the apparent simplicity hides the real challenge: if many users and contracts can all read and update shared state, the chain must define exactly who may change what, in what order, and how every node can agree on the result.

That is why the account model matters. It is not just a different way to keep balances. It is the state model that makes general-purpose smart contracts practical on chains such as Ethereum, and it strongly shapes fees, security assumptions, wallet behavior, transaction ordering, and even which scalability techniques are easier or harder. To understand it, the key idea is this: an account-model blockchain is a state machine over named locations. Transactions do not merely consume old objects and create new ones. They mutate a global mapping from addresses to account state.

Once that clicks, many downstream details make more sense. Nonces exist because mutable accounts need replay protection. Gas exists because arbitrary stateful computation needs explicit resource limits. Smart contracts feel like applications because contract accounts can preserve storage across calls. And many security failures look the way they do because bugs in shared mutable state are often bugs about authorization, ordering, or assumptions about which account is authoritative.

What does it mean that state lives at addresses in an account model?

At the heart of the account model is a simple question: when the chain says Alice has 5 units and Bob has 3, where is that fact stored? In an account-based system, it is stored directly in the current state associated with Alice’s and Bob’s addresses. If Alice sends Bob 2, the chain updates Alice’s account balance from 5 to 3 and Bob’s from 3 to 5. The important thing is not just the arithmetic. It is that the system treats those accounts as persistent entities whose state survives from one transaction to the next.

Ethereum’s execution-layer specification makes this explicit. The world state is a mapping from 160-bit addresses to account states, and implementations are assumed to maintain that mapping in a modified Merkle Patricia trie. That trie root acts as a cryptographic fingerprint of the whole state. In ordinary language, the chain’s “current truth” is a large authenticated key-value map: look up an address, and you get the state for that account.

This differs from the UTXO model in Bitcoin, where the ledger does not primarily store account balances. Instead, it stores unspent transaction outputs, and a wallet balance is the sum of outputs spendable by that wallet. Bitcoin’s model defines a coin as a chain of digital signatures, and transactions consume specific prior outputs to create new ones. The account model chooses a different abstraction. It says: rather than tracking many spendable fragments, store the present state of each account directly.

That choice is not merely cosmetic. It changes what the chain is naturally good at. When state lives at addresses, a contract can keep persistent variables such as balances, permissions, auction status, or lending positions without reconstructing them from sets of unspent outputs. That is one major reason Ethereum chose the account model for more expressive smart contracts. The tradeoff is that shared mutable state is powerful, but harder to reason about safely.

What fields make up an account on Ethereum and what do they do?

An account-model ledger needs a precise definition of what an account is. In Ethereum, an account state has four canonical fields: nonce, balance, storageRoot, and codeHash.

The balance field is the easiest to understand: it is the amount of native currency held by the account. But balance alone is not enough, because a mutable global state needs a way to tell whether a transaction is new or a replay. That is the role of the nonce. For an externally-owned account, the nonce counts transactions sent from that account. Because only one transaction with a given nonce can be executed for that account, old signed transactions cannot simply be replayed forever. For contract accounts, the nonce has a different meaning: it counts contracts created by that account.

The other two fields are what turn the account model from a simple balance ledger into a programmable state machine. codeHash identifies the account’s code on the virtual machine. On Ethereum, contract accounts are controlled by code rather than private keys, and the code referenced by codeHash is what executes when the account receives a message call. storageRoot points to another authenticated trie that holds the account’s persistent storage. In effect, the global state maps addresses to accounts, and contract accounts themselves point to their own storage subtrees.

This gives a useful mental picture. An externally-owned account is like a state entry with a balance and an authorization counter. A contract account is like a small persistent application container: it has a balance, an identity, code to run, and private storage that survives between calls.

Ethereum developer documentation presents the same distinction at a higher level. There are two account types: externally-owned accounts, controlled by private keys, and contract accounts, controlled by code. An EOA can initiate transactions. A contract account cannot wake itself up arbitrarily; it can only act in response to being called during transaction execution.

That asymmetry matters. It means the protocol has a clear outer boundary for execution: some actor external to the chain signs an instruction, and that instruction can trigger code inside contract accounts. The chain is therefore stateful and programmable, but still anchored by explicit transaction initiation.

How does a transaction produce a deterministic state transition in an account model?

The account model becomes real only when we ask what a transaction does to state. Here the right abstraction is not “sending coins” but state transition. Ethereum formalizes this with a state transition function, written as Υ(σ, T), where σ is the current world state and T is a transaction. The output is the next state. At the block level, the block transition function applies that transaction transition repeatedly across the block’s transaction list.

The important point is determinism. Every honest node takes the same prior state and the same ordered list of transactions, applies the same rules, and must compute the same next state. If Alice’s transaction runs before Bob’s, the result may differ from the case where Bob’s runs before Alice’s. So in an account model, ordering is part of the semantics, not just a matter of presentation.

A simple transfer shows the mechanism. Suppose an EOA controlled by Alice has a balance of 10 and nonce 7. She signs a transaction sending 3 units of native currency to Bob, with nonce 7 and some gas limit. When the transaction is processed, nodes verify that the signature authorizes this account, that the nonce matches the account’s current nonce, and that the sender can pay both value and fees. If valid, the sender’s balance decreases by the transferred amount and fees, Bob’s balance increases by the transferred amount, and Alice’s nonce becomes 8. The state root changes because the underlying authenticated trie now encodes different account values.

A contract call follows the same pattern at a higher level of complexity. Suppose Alice calls a token contract to transfer tokens to Bob. Her externally-owned account still pays fees and increments its nonce. But the transaction also triggers execution of the contract code referenced by the token contract’s codeHash. That code reads from and writes to the contract’s storage, perhaps reducing Alice’s token balance and increasing Bob’s token balance inside the token contract’s own storage tree. Native currency may not move at all beyond fees, yet the world state still changes materially because contract storage changed.

This is where the account model really shows its character. The ledger is not just updating balances of currency accounts. It is updating a global graph of account states and contract storage under deterministic execution.

Why do account-model chains use nonces and how do they prevent replay?

A reader new to the account model might treat the nonce as an implementation detail. It is not. In a mutable account ledger, the nonce solves a deep problem: a valid signature should authorize exactly one intended state transition in a specific sequence, not an unlimited class of repeated transitions.

If transactions were just signed messages saying “send 1 ETH to Bob,” anyone who saw the message could rebroadcast it repeatedly. The chain needs a way to distinguish the next authorized action from an old one. The nonce provides that by tying each transaction to the sender’s current sequence number. Once a transaction with nonce n is executed, the account’s nonce becomes n + 1, and the old signed instruction no longer matches current state.

Ethereum’s nonce also helps define ordering among a single account’s transactions. If a wallet signs nonce 10 and nonce 11, nodes know that nonce 11 cannot be executed first. This is not just replay protection but a per-account sequencing rule.

Replay can also happen across chains, which is why Ethereum introduced chain-aware signing in EIP-155. After that change, the chain identifier is included in the transaction signing hash, and the signature encoding reflects the chain ID. The mechanism is conceptually simple: a signature should bind not only to transaction contents, but also to the specific network where it is intended to be valid. Without that, the same signed transaction might be valid on another chain that shares the same transaction format and account keys.

So there are really two layers of replay protection in account-model systems like Ethereum. The account nonce says, “this is the next authorized action from this account.” The chain ID says, “this action is intended for this chain, not some sibling network.”

Why are smart contracts more natural on account-model blockchains?

The account model is especially attractive when a blockchain wants contracts that look and behave like persistent applications. A contract account can own assets, maintain storage across transactions, and expose callable functions. That is a natural match for exchanges, lending markets, stablecoins, DAOs, games, identity systems, and many other on-chain applications.

The reason is straightforward. Many applications need a stable place where state accumulates. A lending protocol wants to track deposits, debts, collateral, interest indexes, and permissions over time. A token contract wants to remember balances and allowances. In an account model, this is native: the contract is itself an address in global state, and its storage persists until changed.

This convenience is precisely what Cardano’s EUTXO research paper highlights when contrasting ledger models. The paper notes that Ethereum chose the account model explicitly to facilitate more expressive smart contracts, but that this comes with shared mutable state, which complicates semantics and can create security vulnerabilities. That is a good summary of the trade. The account model makes many application patterns easier to express, because the state lives in one obvious place. But because many transactions can contend for or depend on that same state, reasoning about behavior becomes harder.

A common misunderstanding is to think smart contracts “run continuously” once deployed. In the account model, they do not. The contract’s code and storage persist, but execution is still event-driven. A contract account can only send messages in response to receiving a transaction or internal call. Persistence belongs to state, not to a continuously running process.

How do gas and fees relate to stateful computation and long‑term state growth?

Once transactions can do more than simple transfers, the protocol needs a way to price computation and storage. Ethereum handles this through gas. Every transaction specifies a gas limit, and execution consumes gas according to protocol rules. If the sender cannot cover the required fees, the transaction cannot proceed. This is tightly tied to the account model because execution changes balances and storage directly.

Post-London Ethereum adds another layer with baseFee and priority fees. Every included transaction must pay the block’s base fee, which is burned, and may also pay a priority fee to the block beneficiary. Type-2 transactions expose maxFeePerGas and maxPriorityFeePerGas, letting the sender bound what they are willing to pay.

Why does this belong in an explanation of the account model rather than a separate discussion of fees? Because in an account-based smart contract platform, fees are not just payment for block space. They are also the mechanism that meters stateful computation. A transaction can trigger code that reads and writes storage, creates contracts, touches many accounts, and consumes validator resources. Gas makes those effects explicit and bounded.

State growth also becomes a first-class concern. Because accounts and contract storage persist, the chain accumulates long-lived state. Ethereum’s specification defines empty and dead accounts carefully, and client implementations worry about pruning, checkpointing, and long-term state management. The protocol gives the abstract model, but operational questions of how clients manage ever-growing state are more open-ended.

Other account-based systems expose the same issue in different ways. Solana, for example, also uses accounts as the fundamental state unit, storing network state in a key-value store from addresses to account records. But it makes storage costs more explicit through rent-like minimum balance requirements proportional to account data size. The mechanism differs, but the underlying pressure is the same: persistent on-chain state is expensive, so the system needs rules that discourage unlimited accumulation.

Do different blockchains implement the account model differently?

“Account model” is often used as if it named a single design, but in practice it names a family resemblance. The shared core is persistent state addressed by account-like identifiers. The details vary substantially.

Ethereum’s version centers on a world state mapping addresses to four-field account records, with contract storage hanging off storageRoot. Solana also uses accounts as the fundamental state unit, but each account has fields such as lamports, data, owner, executable, and rent_epoch, and only the owner program can modify an account’s data or debit its lamports. That means “account-based” does not imply “Ethereum-like” in every execution detail. Solana’s permission model and explicit account passing lead to different tradeoffs around safety and performance.

Some newer systems deliberately move away from classic account semantics. Sui describes its design as an object-centric alternative to the traditional account model, treating on-chain values as first-class objects with ownership and execution semantics aimed at parallel execution without global account locks. Move-based systems more broadly emphasize resource semantics, where digital assets are represented as resource types with constrained movement rules. These designs are responding to a real pressure point in account models: if many transactions can touch shared state, parallel execution becomes difficult and authorization logic becomes subtle.

So the fundamental part of the account model is persistent named state. The rest (exactly what fields accounts contain, who can mutate them, how execution is scheduled, whether state is account-centric or object-centric) is partly convention and partly architectural choice.

Account model vs UTXO: what tradeoffs should you know?

The cleanest way to see what the account model is solving is to contrast it with UTXO systems. In Bitcoin, outputs are created and later spent in full. Balance is a derived wallet view over many UTXOs. Transactions combine and split value through inputs and outputs, often creating change outputs. Authorization is attached to spending conditions on outputs rather than to mutations of a persistent account balance.

That makes some properties simpler. There is no per-account mutable balance to update. There is no global account nonce. Independent UTXOs can often be reasoned about locally. This localness is one reason UTXO systems are attractive for certain forms of analysis and parallelism.

But the same structure makes long-lived application state less direct. If a contract needs to maintain an evolving state machine, the system must encode continuity through outputs, spending rules, and off-chain coordination. Cardano’s Extended UTXO model shows that this can be done in a sophisticated way by adding datums and deterministic transaction context while preserving UTXO-style dataflow. The point is not that account models are universally better. It is that they make persistent shared application state the default abstraction rather than something reconstructed from transaction graph structure.

So the deepest difference is this: UTXO models treat value as discrete spendable outputs; account models treat state as persistent mutable records. The more your application wants a stable stateful actor, the more natural the account model feels. The more you want local reasoning over independent pieces of value, the more attractive UTXO-like approaches can be.

What common failures and security risks arise from shared mutable account state?

The power of shared mutable state is also where many problems begin. If contracts keep persistent storage and many callers can interact with it, bugs become bugs about sequencing, reentrancy, stale assumptions, missing authorization checks, or incorrect identification of which account data is trustworthy.

That is why account-model systems have repeatedly needed stronger abstractions above the base model. Ethereum’s account abstraction work, such as ERC-4337, is a good example. Traditional Ethereum accounts hardcode an important distinction: EOAs are authorized by protocol-level signature checks, while contract accounts are controlled by code but cannot originate transactions in the same way. ERC-4337 loosens this by introducing UserOperation objects handled through an alternative mempool and an EntryPoint contract, allowing signature semantics and account policies to be defined by smart contract accounts themselves. In other words, developers are trying to make the account model more programmable even at the level of transaction authorization.

Real incidents also show the danger of account semantics when authority is mis-specified. Ronin’s bridge breach turned on control of validator private keys and delegated signing relationships that were not properly revoked. In practical terms, too much power sat behind too few account-controlled authorities. The Wormhole exploit on Solana, though platform-specific, illustrates a related lesson from another account-based environment: if a program fails to verify that the accounts it was given are truly the authoritative ones it expects, an attacker may manufacture convincing but false state context. In account systems, which account is this, and who is allowed to treat it as authoritative? is often the critical security question.

This does not mean the account model is flawed in itself. It means its convenience comes with a larger semantic surface area. Once the ledger stores rich shared state, programmers and protocol designers must be exact about permissions, ordering, and invariants.

Conclusion

The account model is the blockchain design where the ledger stores persistent state directly at addresses. That state may be as simple as a balance and nonce, or as rich as contract code plus private storage. Transactions then act as deterministic state transitions over that global mapping.

What makes the idea useful is also what makes it demanding. It is a natural model for smart contracts because applications want persistent state. But persistent shared state creates hard problems around replay protection, ordering, fees, storage growth, and security. If you remember one sentence tomorrow, make it this: the account model turns a blockchain into a shared state machine indexed by addresses, and nearly everything else follows from that choice.

What should you understand before using the account model in production?

Understand the account model risks that matter for transfers and trading, then use Cube Exchange to perform the necessary checks and execute trades or deposits. On Cube, fund your account with a supported on‑chain deposit or fiat on‑ramp and use the exchange’s market or transfer flows to act after you confirm network, contract, and fee details.

1. Verify the asset and network on a block explorer: copy the token or contract address shown in Cube, open it on a trusted explorer, and confirm the chain ID and bytecode/metadata match the official project sources.
2. Deposit funds into your Cube Exchange account using the same network you verified (do not mix ERC-20 on Ethereum with a different chain); choose the fiat on‑ramp or an on‑chain transfer and confirm the destination address exactly.
3. Open the relevant market on Cube and pick an execution type; use a limit order for low‑liquidity or high‑slippage tokens, or a market order for immediate execution; set a tight slippage tolerance for volatile pairs.
4. Before withdrawing or making large position changes, wait for chain‑specific confirmations (for example, typical Ethereum finality windows) and review Cube’s estimated gas/fee summary shown at order/withdrawal time.