Section 10
Scalability and Performance
Throughput, finality, bandwidth, and state growth, with their trade-offs
10.1Throughput and Latency
The 100-shard architecture described in Section 5.1 gives a theoretical ceiling of 100,000 transactions per second, with a sustained, heterogeneous-fleet target of 60,000–80,000+ TPS once the realistic mix of node hardware and network conditions is accounted for. The protocol's stable-state benchmark — the figure the demand factor in Section 7.1 measures actual usage against — is set at 15,100 TPS.
| Metric | Specification |
|---|---|
| Theoretical maximum throughput | 100,000 TPS (100 shards × 1,000 parallel transactions each) |
| Sustained throughput (heterogeneous fleet) | 60,000–80,000+ TPS |
| Stable-state benchmark | 15,100 TPS |
| Intra-shard confirmation | 0.3–0.5 seconds |
| Owned-object fast path | ~8–10 milliseconds |
| Cross-shard finality | ~8 seconds |
| Fork probability (10,000-node network) | 0.0007% |
10.2Energy Cost and Hardware-Tier Performance
Average energy cost per transaction is targeted at 0.00034 kWh. Performance varies meaningfully by node tier and execution mode, which is precisely the trade-off the dual-mode virtual machine in Section 5.3 is designed to manage rather than ignore.
| Metric | Specification |
|---|---|
| Full Mode contract execution | 0.4 ms per contract |
| Full Mode high-frequency operations | 0.06–0.1 ms |
| Lite Mode (interpreted) | ~30x slower than native code, ~10x faster than an equivalent Python script |
| Lite Mode (RISC-V, ahead-of-time compiled) | Near-native speed; under 5% CPU duty cycle |
| Edge-tier daily battery impact | ~1% (energy-attestation submission only) |
| Local inference latency (edge tier) | Under 50 ms on a 256 KB ARM Cortex-M4 |
| Primary signature generation | 0.1 ms, identical across all hardware tiers |
10.3Bandwidth and State Growth
The Merkle Mountain Range storage structure described in Section 5.5 keeps annual state growth to roughly 8.5–12.5 GB, with individual proofs compact at just 4–8 KB regardless of how large the overall ledger becomes — a property that comes directly from the proof structure described in Section 3.1, where each participant only needs a proof for their own coins rather than the entire transaction history.
Network bandwidth is managed through adaptive compression and filtering, cutting typical payload size by 50–70%, and the QUIC-based networking layer described in Section 5.4 is specifically tuned for the lower-bandwidth 2G and 4G connections common across the protocol's target deployment regions.
10.4The Privacy-Throughput Trade-off
As detailed in Section 7.7, optional privacy transactions carry roughly 1.5–2x the overhead of a standard transaction, and aggregate throughput degrades gradually as Cash Mode adoption increases — from no measurable impact at low adoption to a 36% reduction at 50% adoption, a point at which the dynamically rising privacy fee begins to self-limit further growth.
This is a deliberate, transparent trade-off rather than a hidden cost: a network that wants to support meaningful privacy adoption must accept some throughput cost for the share of transactions that use it, and the fee mechanism is designed so that cost scales with usage rather than being absorbed uniformly by the whole network.
10.5Design Trade-offs, Stated Plainly
Three trade-offs are worth stating explicitly rather than leaving implicit.
First, supporting hardware as constrained as a $3 microcontroller necessarily means that tier's contribution to network-wide computation (full inference, advanced privacy mixing) is smaller than a GPU validator's — the protocol addresses this through verified commitments rather than raw computation, as described in Section 5.6, but it does not pretend a $3 device computes as much as a server.
Second, the persistence-gating mechanisms that protect monetary policy from manipulation (Section 7 and 8.5) mean the system intentionally reacts more slowly to short-term signals than a less-guarded design would — this is a deliberate stability-over-speed choice.
Third, optional privacy genuinely costs throughput, and the protocol does not claim otherwise; it manages that cost through dynamic fees rather than eliminating it.