Vela: a deterministic spot exchange research system

Context

Fast matching and trustworthy settlement are separate engineering problems. A central limit order book can execute deterministically in memory, while custody, accounting, data availability, and dispute enforcement require their own systems and evidence.

Vela explored that boundary with a Rust spot-exchange engine, wallet-signed orders, HTTP and WebSocket interfaces, a Sepolia contract demo, and research components for commitments and proving. The project is no longer under active development.

The architecture below describes implemented code and clearly labels prototype and design-stage parts. Source: Vela's exchange repository and trust-model documentation. The exchange repository is private.

Benchmarks

These archived measurements were recorded May 20, 2026 on an Apple M3. They have not been reproduced on the current code and are not current exchange capacity. The realistic_mm_workload timing covers single-threaded engine.process() calls, excluding networking, signatures, database commits, and settlement.

Old Pulse comparison

The archived comparison used different hardware and did not establish equivalent workloads or request-outcome validation. These values are shown for the historical record, not as a defensible speedup claim.

Read the technical report and methodology ↗

Architecture

Vela's core is a Rust workspace. The API authenticates and routes requests; the matching engine processes an ordered stream; state and committer components produce local commitments and batch records. A separately configured PostgreSQL ledger path can make a matched financial effect durable before acknowledgement. That path is implemented in code, but it has not established a production custody service.

The order of these steps matters: in ledger-backed mode, successful customer-facing financial responses wait for the database commit. In testnet-demo mode without a ledger, balances are non-authoritative demo state.

State

Order books and hot account state are held in memory. The state crate maintains typed keys, a cache, batch sequence, and deterministic roots for research inspection. Snapshots and local write-ahead records support recovery in the demo. These roots are local commitments; they are not evidence that public data availability or on-chain settlement is deployed.

When PostgreSQL is configured, customer available and locked balances are read from the ledger projection. Startup replay checks journal legs against the balance projection and replaces financial values recovered from local snapshots. This narrows the trust boundary for that configuration but does not complete deposit indexing, withdrawals, reconciliation, or disaster recovery.

Matching Engine

Each market is a price-time priority central limit order book. Price levels use ordered maps and resting orders retain FIFO order within a level. The engine handles GTC, post-only, IOC, and FOK requests with fixed-point arithmetic, nonce checks, balance reservations, fees, and deterministic response events.

Delta buffers let a rejected or unfillable operation discard its proposed changes. The sharded dispatcher batches independent market work; shared financial state requires careful merge rules. An October 2026 regression exposed a cross-market balance overwrite in an older measured source snapshot. The named reproduction passes after the fix, but that is a regression result, not a financial audit.

API Handler

The Axum API exposes signed order and cancellation endpoints, market data, account views, and WebSocket feeds. Wallet signatures authenticate order intent. A short-lived, account-bound HTTP session protects private account reads. The public market data path and authenticated account path serve different information.

In testnet-demo mode, some routes intentionally operate without an authoritative ledger. Ledger-backed mode disables legacy balance-mutating routes until each effect has a balanced, idempotent journal transaction. These are runtime boundaries in the code, not a claim that a hosted production exchange exists.

Committer

The committer packages ordered requests and fills into batch records and calculates content hashes. The current data-availability adapter writes batch files locally. A hash can reveal changes to data that is available, but it cannot ensure that the operator publishes or retains that data for independent users.

A separate matcher-to-ledger path posts balanced financial effects and an outbox event in one serializable PostgreSQL transaction when configured. The API publishes the proposed engine state only after that commit. This protects the specified commit boundary; custody, withdrawal completion, and public batch availability remain separate launch blockers.

zkVM

The zkVM crate includes deterministic replay and an SP1-compatible prover adapter behind configuration. The default provider is PlaceholderProver. Production configuration fails closed without the required external prover infrastructure, and the current demo has no deployed on-chain verifier or penalty mechanism.

Consequently, Vela must not be described as trustless, proof-secured, or censorship resistant today. Proof-based verification and forced inclusion were research directions, not shipped customer protections.

Interesting Features

Market-Maker Credit System

The engine models aggregate quoting limits across markets and can evict older resting orders when limits are breached. A rolling 20-entry nonce window supports overlapping signed requests without accepting a duplicate nonce. Both are engine behavior; neither creates a production credit facility.

Market Data Feeds

WebSocket topics carry order-book, trade, market, and authenticated account events. Sequence numbers support gap detection and reconnection. Reference charts may use external spot prices, while testnet orders execute only against Vela's separate synthetic book.

Optimizations

The engine uses fixed-point values, ordered price levels, a compact nonce ring, copy-on-write deltas, and batch dispatch to reduce work on the order path. The archived benchmarks measure isolated engine operations, not the incremental contribution of every optimization in production.

Extensions

The repository also contains experimental work on a committee, TEE attestation, perpetual margin math, FIX sessions, and agent interfaces. Several paths are feature-gated, use placeholders, or lack full UI and settlement integration. They are prototype surfaces and research scaffolding.

FAQ