Bitcoin tracks money as discrete coins that get consumed and recreated. Ethereum tracks money as account balances that get modified in place. This change cascades into everything else: how transactions look, what state means, how contracts hold funds, why nonces exist. If you only take one new idea from this module, take this one.

In the previous module you learned how Bitcoin tracks state with UTXOs: unspent transaction outputs. Every coin in existence is a UTXO sitting in the chain's database, locked to some address by a script. To spend it, you reference it as the input to a new transaction, prove you can satisfy its lock, and create new UTXOs as outputs. The old UTXO is consumed. The new ones are created. The chain's state at any moment is the full set of currently-unspent outputs across all addresses.

Ethereum uses a different model called the account model. Instead of tracking individual coins, the chain tracks accounts. Each account has an address, a balance of ETH, and possibly some additional state. When Alice sends 3 ETH to Bob, the chain subtracts 3 from Alice's balance and adds 3 to Bob's balance. Nothing gets consumed or created. The balances just change.

This sounds simpler. It is, conceptually. The implications take longer to absorb.

An account on Ethereum has four fields:

• A balance of ETH, stored as an integer in wei, where one ETH is 10^18 wei
• A nonce, which is a counter that increases by one with every transaction the account sends
• A code hash, which is empty for regular user accounts and points to the deployed bytecode for contract accounts
• A storage root, which is empty for regular user accounts and points to the contract's storage tree for contract accounts

Two kinds of accounts exist. Externally owned accounts, or EOAs, are controlled by a private key. Their code hash and storage root are empty. They behave like a Bitcoin address: you sign transactions with the matching key to spend their balance or trigger something else on the chain. Contract accounts are controlled by code. They have a balance like any other account, but they also have code that runs when called and storage that persists between calls. They have no private key. Nobody can directly sign transactions from a contract account. The only way to move a contract's funds or change its state is to call its code from another account, and the code decides what happens.

The chain's state at any moment is the combined state of every account that exists. Every EOA and every contract. Their balances, their nonces, and, for contract accounts, their code and their storage. When a block is produced, every full node applies the block's transactions to this state, computes the new state, and rejects the block if its claimed result doesn't match.

The same payment looks completely different in the two models.

In Bitcoin, if Alice wants to send 3 BTC to Bob and she has a single 10 BTC UTXO, her transaction consumes that UTXO as its input and creates two outputs: 3 BTC locked to Bob's address, and 7 BTC locked back to one of her own addresses as change. After the transaction, her old UTXO no longer exists. In its place are two new UTXOs, one belonging to Bob and one belonging to her.

In Ethereum, if Alice wants to send 3 ETH to Bob and she has a balance of 10 ETH, her transaction just says: send 3 ETH to Bob. After the transaction, her balance is 7 and Bob's balance has increased by 3. There are no outputs, no change addresses, no UTXOs being consumed.

The Bitcoin transaction is a graph operation: it removes one node from the UTXO set and adds two new ones. The Ethereum transaction is a mutation: it changes two existing entries in the account state table. The Bitcoin version preserves nothing. The inputs and outputs are entirely new objects. The Ethereum version preserves the accounts. Only their balances move.

Three things follow from this choice that matter for the rest of this course.

Contracts can have their own state. A contract account stores key-value pairs that persist across calls. The contract's code reads and writes this storage as transactions come in. This is what makes Ethereum programmable. In the UTXO model, there is nowhere for a program's data to live between transactions. The chain's state is just a set of locked coins. In the account model, the chain's state has structure: each account has its own slice of storage that the protocol tracks. A contract can have a million users with a million different balances stored in it. This is impossible to express cleanly in UTXOs.

State changes are simpler to reason about. In Bitcoin, "what is Alice's balance" requires scanning the entire UTXO set for outputs locked to her addresses and summing them. In Ethereum, "what is Alice's balance" is one lookup in the state table. This makes contract code dramatically simpler. A token contract just keeps a mapping from address to balance and updates it on every transfer. The protocol doesn't need to know what the contract is doing. The contract manages its own state.

Parallelism is harder. Two Bitcoin transactions that touch different UTXOs are independent and can be processed in parallel. Two Ethereum transactions that touch the same account may conflict. This includes cases where both transactions only read from a popular contract's storage. The Ethereum protocol processes transactions sequentially within a block to handle this. Most newer chains that came after Ethereum, including Solana, build elaborate machinery to recover the parallelism Ethereum gave up.

There's one more piece of the account that needs explaining.

Every account has a nonce: a counter that starts at zero and increases by one with every transaction the account sends. When Alice signs a transaction, she includes her current nonce in it. The chain only accepts the transaction if the nonce matches what it expects from Alice's account.

The nonce exists because the account model has a problem the UTXO model doesn't. In Bitcoin, a transaction is uniquely identified by the UTXOs it consumes. If Alice broadcasts the same transaction twice, the second one fails because the first one already consumed the input. Replay is impossible by construction.

In Ethereum, a transaction is "send 3 ETH from Alice to Bob." If someone rebroadcasts that same signed transaction, the network needs a way to tell it's the same one. The nonce solves this. The first transaction Alice sends has nonce 0. If the network sees a second transaction from Alice with nonce 0, it rejects it as a duplicate. Alice's next transaction must use nonce 1. Then nonce 2. And so on.

The nonce also enforces ordering. If Alice broadcasts transactions with nonces 5, 6, and 7, the network will include them in that order regardless of when they arrive. Transaction 6 can't be processed until transaction 5 is in a block. This matters for contracts that depend on a specific sequence of calls.

Most of the code you write in this course will assume the account model without naming it. When a token contract does balances[alice] -= 3 and balances[bob] += 3, that's the account model at work, inside a contract. When a transaction reverts halfway through and the chain rolls back the state, that's the account model at work, at the protocol level. When you debug why a transaction "stuck" with the wrong nonce, that's the account model at work, at the wallet level.

The UTXO model produces a kind of cryptocurrency that's good at being money. The account model produces a kind of cryptocurrency that's good at being a substrate for arbitrary programs. Ethereum picked the second one. The rest of this module is what falls out of that choice.