Two designs dominate how blockchains record who owns what. Account-based systems, used by Ethereum, keep a running balance for every address and update it in place with each transaction. UTXO systems, the model Bitcoin introduced, store no running balance. They track value as a set of discrete outputs, each one spendable exactly once.
Both work. For general-purpose computation, the account model fits well. For a network whose main job is moving money at volume, the decisions inside each model start to matter, and they pull in different directions.
How nonces slow things down
In an account-based chain, every transaction from an address carries a nonce: a counter that starts at zero and goes up by one with each transaction the account sends, as Ethereum's transaction documentation describes. The nonce does two jobs. It fixes the order transactions execute in, and it stops the same signed transaction being replayed.
That ordering is strict. A transaction with nonce 6 cannot confirm before the one with nonce 5. If a low-nonce transaction gets stuck, everything queued behind it stalls until it clears. Sending many transactions in parallel from one account means tracking and incrementing the nonce precisely, which gets awkward when several processes share the same account.
For a payment service settling thousands of transactions an hour, that strict sequential ordering is a real constraint.
Replay risk and mutable state
Because an account transaction is a signed instruction to change a shared balance, the same instruction can be valid in more than one place unless something prevents it. On a single chain, the nonce handles that. Across chains, it took an explicit fix. After Ethereum split into Ethereum and Ethereum Classic in 2016, a transaction signed on one chain could be replayed on the other, because the signature carried nothing tying it to a specific network. EIP-155 closed the gap by folding the chain ID into the signed data.
Every serious account-based chain handles replay today. The model carries this work because balances are mutable shared state, and shared state has to be guarded.
What changes with UTXO
A UTXO ledger has no balance to update. Its entire state is the set of unspent outputs. A transaction names specific outputs as its inputs, consumes them, and creates new outputs in their place. Your balance is the sum of the outputs you control.
Spend an output and it leaves the set permanently. A few things follow directly from that. Replay becomes impossible on its own terms. A transaction references specific inputs, and once those inputs are spent they no longer exist, so the transaction can never apply twice. Double-spends fail the same way, since two transactions cannot both consume the same output. There is no nonce to manage, because unrelated transactions touch different outputs and their order relative to each other does not matter. That independence is what lets a network validate many transactions at the same time. A single transaction can also take inputs from several parties and produce several outputs that all settle together or not at all, which makes atomic multi-party transfers a native operation, with no contract to write for it.
Why eCurrency is UTXO-native
eCurrency is built on the UTXO model from the base layer up, because payments are the whole point of the network. State is a set of outputs, each one carrying its value, the script that locks it, and the block height where it was created.
Blocks arrive every 10 seconds. The same output independence that rules out nonces also applies here: transactions touching different UTXOs don't have to wait on each other, so the network isn't bottlenecked by a shared state that every transaction has to pass through in sequence.
Staking uses the same outputs. Each UTXO carries a stake weight set by its value and its age, measured in blocks since it last moved, and validators are selected by accumulated stake weight. There is no bonding, no lockup period, and no slashing. Coins stay liquid and spendable while they help secure the chain.
Contract logic runs client-side. The network verifies the resulting state transition, so code never has to execute across every node, which means there is no global virtual machine and no gas market bidding up the cost of a payment.
For a network built to settle payments, that's the case for choosing UTXO: replay and double-spends are ruled out by the ledger's own structure, not by an added mechanism, and the capital securing the chain never has to sit frozen to do it.
