Security Model

Scope & threat model

Velarium’s security posture is defined by three moving parts: Shipyard (compile/synthesis), Celerity (runtime/scheduler), and Vehicles (sandboxed native execution units). The trusted computing base (TCB) is the operator’s environment (host OS/kernel/application and system services/hardware) plus Velarium’s own runtime, compiler pipeline and system code within Vehicles. The adversary is the workload: contract bytecode and transaction inputs that may be malicious, and transaction patterns that attempt to stall execution or amplify resource usage.

Trust boundaries

Velarium draws a hard boundary between untrusted contract code and the trusted executor. Recompiled contracts execute only inside Vehicles. The host runtime (Celerity), the compilation pipeline (Shipyard), and the integration adapters are trusted by the deployment. In clustered deployments, the intent is to tolerate runtime faults (nodes disappearing, link loss) without producing incorrect outputs.

Compile-to-native and native-code-execution attack surface

Compiling adversarial bytecode into native code expands the attack surface. Malformed or adversarial contracts may attempt to trigger compiler/codegen bugs, access restricted memory or cause undefined or faulty behavior at runtime. Responsibilities for mitigating this is split between Shipyard and Celerity

Shipyard mitigations:

  • Input contract validation: the contract needs to be valid (e.g. for EVM, all JUMP/JUMPI static targets are JUMPDEST).
  • Velarium’s intermediate representation ABI is confined to a safe set. For example system calls, arbitrary memory accesses or unchecked jumps to non-deterministic offsets are non-emittable.
  • Software Fault Isolation (SFI) hardening: emitted code is statically confined to the host sandbox boundaries. Vehicle is limited to it’s own virtual memory address space and doesn’t have the tools to escape it.
  • Compiler toolchain isolation: a fatal error in the compiler does not cause system level errors.
  • Artifacts are cached and addressed by hashes to avoid “silent drift” across machines or builds.

Celerity mitigations:

  • Vehicles execute inside a sandboxed envelope with deterministic and scoped fail behavior.
  • Memory accesses are constrained to a dedicated arena using Software Fault Isolation ****provided by Shipyard.
  • Enforces W^X (write-xor-execute) memory and adds guard pages to mitigate JIT-style attacks and out-of-bounds behavior.
  • Optionally hardware mechanisms (e.g., MPK/PKU, MTE) can be used for additional layer of defense.

Adversarial contracts & DoS resistance

A contract can be “malicious” without exploiting memory safety: it can attempt to stall the pipeline, create hotspots, or amplify resource usage (CPU, memory, trace volume). In addition to techniques used to mitigate normal contention, Velarium has tools to detect and report on pathological contention allowing the system to take preventative actions:

  • Critical path manipulation detection: a case of creating a series of transactions that cause the parallezation to collapse due to carefully crafted contention pattern. It is possible to detect specific offending contracts even when they are hidden behind a seemingly disjoint entry points.
  • Scanning contracts (those that access thousands+ storage slots) and contracts with dynamic CALL targets are detected and marked during compilation, simplifying detection of possible hotspots in advance.

Correctness

Security includes correctness: an executor that produces a wrong state transition is a security failure. The main correctness surfaces are:

Celerity’s commit rules: the committed state transition must be sequentially equivalent and any invalidated speculation attempt must not affect it.

Correctness of Vehicles: all observable behavior of a Vehicle must be equivalent to a direct interpretation by the source VM, and have deterministic failure behavior.

Oracle/state interactions semantics: in particular, effectful oracle calls must be controlled so that retries/deferrals do not accidentally duplicate effects; the design treats oracle semantics explicitly (idempotent vs effectful) and buffers/commits effects at well-defined points.

Validation & assurance

The primary assurance strategy is differential validation against a serial reference: the same inputs should produce the same committed state transition and the same trace artifacts (within the configured schema). Compiler toolchain is fuzzed to ensure stability. Adversarial contention handling and crash recovery is tested using corpora of crafted contracts and transaction patterns.

What’s out of scope

Velarium does not claim to defend against a fully compromised operator environment, host OS/kernel or hardware. Cluster behavior focuses on runtime fault tolerance; offline state restoration guarantees are not provided by the cluster layer alone.