Most chains we validate ask the same thing of our hardware: keep up with a block every few seconds and a few hundred transactions inside it. Somnia asks something categorically different. It's an EVM-compatible Layer 1 engineered for over one million transactions per second with sub-second finality, built for fully on-chain games, social apps and real-time entertainment. Validating it forced us to rethink assumptions we'd carried across every Cosmos chain we run. This post is both a partner update and an engineering field report.
What makes Somnia different under the hood
Three design decisions drive Somnia's throughput, and each one has direct consequences for validator operators:
1. MultiStream consensus
Instead of one global chain that every validator writes to in lockstep, each Somnia validator maintains its own data chain, publishing transactions continuously and independently. A separate consensus chain periodically snapshots the heads of all data chains and orders them. Production of data is decoupled from ordering, which means a validator's write path is always hot. There is no "idle time between blocks" to hide slow disks in.
2. Compiled EVM execution
Somnia translates frequently-executed EVM bytecode into native machine code rather than interpreting it. Sequential execution on one very fast core replaces the parallel-execution lottery: performance becomes deterministic, but it also means single-core clock speed matters more than core count, the opposite of how most validator hardware is specced.
3. IceDB storage
Somnia's custom database targets nanosecond-scale reads/writes with deterministic performance reporting. In practice, this is where operators live or die: IceDB rewards NVMe drives with consistent low-queue-depth latency and punishes anything with garbage-collection stalls.
What we changed in our stack
| Dimension | Typical Cosmos validator | Our Somnia spec |
|---|---|---|
| CPU priority | 8–16 balanced cores | Fewer cores, max single-core boost clock |
| Storage | NVMe, ~10k IOPS sustained | Enterprise NVMe, latency-binned, no consumer drives |
| Network | 1 Gbps comfortable | 10 Gbps with headroom for stream gossip |
| Monitoring focus | Missed blocks | Data-chain publish latency, p99 disk write |
The monitoring row is the one that surprised us. On a MultiStream design, the earliest sign of trouble isn't a missed block. It's your data chain falling behind its publish cadence while consensus still looks healthy. We built a custom exporter for publish-lag and alert on it the way we alert on missed precommits elsewhere.
Operator takeaway: on high-throughput chains, benchmark your disks under sustained write load for hours, not minutes. Two NVMe drives with identical spec sheets diverged by 40% in p99 latency after 90 minutes of Somnia-shaped load in our tests.
Partnership status
- Mainnet validator: active since our onboarding cohort, with 99.9% participation and zero missed consensus rounds in the trailing quarter.
- Testnet: we continue to run Somnia testnet infrastructure, where new node releases get 72 hours under our load exporter before we roll them to mainnet.
- Ecosystem support: our public RPC endpoints for Somnia serve dApp developers building real-time applications; dedicated endpoints are available for teams with sustained load, so talk to us.
Why this matters beyond Somnia
The broader industry lesson: as chains push throughput up 100×, validation stops being a commodity. The gap between "runs a node" and "runs a node that never falls behind" becomes visible on-chain, in participation metrics anyone can query. We think that transparency is healthy. It lets delegators reward engineering instead of marketing.
Somnia doesn't just raise the throughput ceiling. It removes the places where mediocre infrastructure could hide.
Want to stake on Somnia through Helios? Head to our networks page. Curious how we keep validators safe while running this hot? Start with our sentry architecture deep-dive.