Account-Based Model

Overview

In an account-based blockchain, the ledger resembles a shared state database. Each account has a current record, and transactions apply state transitions to those records. A simple transfer usually debits the sender’s balance and credits the recipient’s balance, provided the sender has sufficient funds and supplies the expected nonce and fee.

This differs from the UTXO model, where coins are represented as individually spendable outputs. Account-based systems do not generally require a wallet to select multiple previous outputs or create a change output for every payment. This can make balance queries, smart-contract calls, and complex multi-account operations easier to express.

The model also introduces operational constraints. Transactions from one account may need sequential nonces, so later transactions can be blocked by an earlier pending transaction. Global mutable state can create contention when many transactions try to update the same account or contract. Protocols address these issues through mempool rules, replacement policies, parallel execution strategies, or alternative account designs.

For payment applications, the account-based model usually presents a familiar balance-and-transfer interface. However, network fees, token contracts, destination identifiers, and confirmation behavior still vary by chain.

Token balances in account-based systems are not always stored in the base account record. They may live inside a token contract, which means the native balance and token balances require different queries and transfer logic. This distinction is important for wallets and payment systems that support several assets on one network.

Account-based designs also differ from one another. Some use resource-oriented storage, object ownership, or parallel execution rules rather than a single Ethereum-style global state model. The phrase therefore describes a family of approaches, not one universal implementation. Developers should verify how a particular chain handles account creation, fees, authorization, and concurrent transactions.