Every payment system has to answer one question first: when has the money actually moved? On eCurrency, the first confirmation arrives in 10 seconds. That number is the block interval, and it sets how the network behaves under real payment load.
Every 10 seconds the network produces a block. A transaction included in that block has its first confirmation, which is the network acknowledging it and fixing its place in the ledger. For a lot of everyday payments, that first confirmation is enough to act on. For larger transfers, you wait for a few more blocks, and the reason why is worth understanding.
How certainty accumulates
Bitcoin established that you can settle value between strangers with no central operator, and it does this through proof of work, where your confidence in a payment grows with each confirmation that stacks on top of it. eCurrency keeps that idea and changes the engine underneath it.
There is no hash lottery on eCurrency. Each block carries a stake weight derived from the value and age of the coins backing it, and the canonical chain is the branch with the greatest cumulative stake weight. Ordering is deterministic. Two competing blocks at the same height do not start a guessing game about which one will win, because the rule that decides is fixed and economic.
Settlement confidence then grows with depth. To rewrite the last few blocks, an attacker has to out-weigh the honest chain across all of them, and the cost of doing that climbs sharply as the history gets deeper. A small payment and a six-figure settlement do not need the same number of confirmations. The merchant or the settlement desk picks a depth that matches the value at risk, which is the same judgment call retail and banking already make today.
Why not 3 seconds
Shorter blocks come with a cost that is easy to miss. Every block needs time to reach validators across the network before the next one is due. Push the interval down to 3 seconds and that propagation window tightens, competing blocks at the same height become more common, and the pressure builds to run heavier hardware just to keep pace. Chains that run sub-second blocks pay for it with high validator hardware requirements.
eCurrency is built to keep validation reachable on moderate hardware, so it does not chase sub-second blocks. A payment chain gains very little from a 3-second base layer anyway, because the fastest retail payments do not happen on the base layer at all.
Why not 30 seconds
Slow the interval to 30 seconds and you spend responsiveness you cannot get back. The first confirmation is the moment a shopper at a terminal, or a desk closing a batch, is waiting on, and half a minute of waiting is too long for that step.
Ten seconds sits in the workable middle. It is short enough that the first confirmation feels prompt, and long enough to give validators on ordinary machines time to receive and check blocks that can hold up to 65,535 transactions in 8 MB of data. That headroom is where the throughput comes from. Under full load the design approaches 400,000 transactions per minute, without asking every validator to run a data centre.

Where instant payments actually happen
A 10-second confirmation is still slower than a shopper tapping a card expects. The base layer handles that by supporting Lightning-style payment channels on top of its UTXO model. Two parties open a channel, transact back and forth instantly and privately off-chain as often as they want, and settle the net result on-chain when they close it.
The 10-second base layer anchors the channel and guarantees the final settlement. The tap-to-pay speed lives in the channel above it. So the chain does the job it is good at, which is reliable settlement, and instant retail runs on the layer designed for that speed.
That split is the point of the 10-second interval. It confirms and settles value with real economic weight behind it while keeping validators on accessible hardware, and it hands the millisecond retail experience to the payment channels built for that speed.
Reference: eCurrency Whitepaper 2.0, Section 10 (Network Performance and Settlement Model)



