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.