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. The account is a bottleneck by design.
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, which Ethereum sets out in its account documentation. 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.
Parallel validation is what makes the throughput numbers real. Blocks are 8 MB and arrive every 10 seconds, each holding up to 65,535 transactions, which works out to roughly 400,000 transactions per minute at full load, and the protocol reaches that on modest hardware, without specialised validator rigs.
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 instant settlement, the UTXO base layer also works with payment-channel constructions of the kind Bitcoin uses in the Lightning Network.
For a network built to settle payments, that independence between outputs is the whole reason to choose this model. Transactions validate in parallel, replay and double-spends are ruled out by the structure of the ledger itself, and the capital securing the chain never has to sit frozen. That is the model eCurrency runs on.
