Overview

⚠️ Velarium is in early stages: research + discovery are ongoing. Architecture, interfaces, and terminology are subject to change. These docs aims to share the current mental model and intended direction, not a finalized spec.

Velarium is a drop-in, horizontally scalable execution layer for Ethereum and Ethereum-like stacks. It boosts throughput by scaling out and by improving per-core efficiency. Its concurrency model is built for hostile contention, using deliberate scheduling, phase-aware execution, and governance-safe policies to avoid retry storms and sequential fallback.

Goals

We define the following major goals for Velarium:

  • Elastic scale-out on commodity and server hardware, with no distributed locks and two-phase-commits. The throughput must grow linearly with horizontal scaling as long as the contention permits. Built-in NUMA awareness when deployed over server hardware.
  • Predictable behavior under contention. The scheduler must be able to handle highly contended hot-state efficiently and successfully mitigate common cases: liquidations, air-drops, NFT-minting, DEX workloads. The execution must not unexpectedly collapse under contention, and be resilient for DoS attacks. The operator must have observability of contention patterns and measurements to allow enacting informed policy driven decisions.
  • Better hardware utilization. System’s hardware should be tasked with a meaningful job as much as possible. All cores must be tasked with meaningful work as much as possible, IO access must be shadowed, pre-heating is explicit. The pipeline must not stall due to a straggler memory or disk access.
  • Sovereign deployability and minimal stack intrusion. Regulated and air-gapped premises are first-class. Integrating into existing stacks should be a straightforward process and not require major changes in unrelated components.

Integration

Velarium sits between ordering and proving—consuming ordered batches from the sequencer/mempool layer and emitting state transitions plus configurable execution traces into your storage and proof pipelines.

Velarium keeps the existing execution model and semantics. You keep the same ordering contract and the same meaning of a state transition; parallel execution is an internal implementation detail used to produce those results more efficiently. The intent is a rock-solid drop-in integration: correctness and semantics stay fixed while performance evolves.

Execution approach

  • Contention-aware scheduling:
    • Contract bytecode effect analysis for state access patterns.
    • Storage slot-level conflict and scheduling granularity, to allow parallelization on disjoint transaction segments.
    • Cooperative concurrency for advanced scheduling techniques, as well as memory and IO access shadowing.
    • Risk aware speculative state access—accesses that are likely to be invalidated are de-scheduled until later, in a pause-and-resume manner.
  • Special execution phases:
    • RMW phase localization for fast hot-state contention processing.
    • Contention removal of accumulated non-observable update access patterns (e.g. sum = sum + 1, where sum isn’t used anywhere else).
    • Hot-slot isolation to avoid CPU cache thrashing.
  • Hardware-aware runtime:
    • Locality-first scheduling. Transactions are pinned to cores, keeping their cache hot. NUMA boundaries are respected, with minimal cross-node communication.

Constraints & failure modes

  • Must integrate with existing Ethereum and Ethereum-like stacks and be compatible with existing ordering and VM semantics.
  • Hot state and contention are common — and adversarially inducible.
  • Naive speculation can devolve into retry storms or effectively sequential fallback.
  • Execution results must be identical to a non-speculative sequential execution.

Non-goals

Additionally we explicitly clarify what Velarium is not:

  • Not a new chain: not an L2 / rollup / sidechain, and not a shared network to join.
  • Not a token/incentive layer: no new token, no fee/incentive network.
  • Not a consensus / DA / sequencing system: Velarium doesn’t own ordering (bar unordered input), consensus, or data availability.
  • Ethereum-scoped today: designed for Ethereum and Ethereum-like stacks, with room to accommodate other bytecodes/execution models/chains later.