Vordium LabsDocs

Architecture

The path of an operation from a signature to a final block, and who does what along the way.

The parts

Clients sign operations: a wallet or app signs with the account's own key, a program or AI assistant signs with a trading key (a session) or an agent key that the account authorised. Nothing reaches the chain without a signature the chain can check.

Public interfaces take signed operations and serve the committed state: a REST API, a WebSocket stream for markets, a market-maker feed, and Ethereum JSON-RPC. Their addresses are part of the network's own spec:

FactMainnetTestnet
REST and JSON-RPChttps://rpc.vordium.comhttps://rpc-testnet.vordium.com
EVM JSON-RPChttps://rpc.vordium.com/evmrpchttps://rpc-testnet.vordium.com/evmrpc
Market WebSocketwss://rpc.vordium.com/wswss://rpc-testnet.vordium.com/ws
Market-maker feedswss://rpc.vordium.com/feedswss://testnet.vordex.xyz/chain/feeds
Network spechttps://rpc.vordium.com/network-spec.jsonhttps://testnet.vordex.xyz/network-spec.json
Agreed factshttps://rpc.vordium.com/truth/v1https://rpc-testnet.vordium.com/truth/v1

Validators run VordiumBFT and VordCore. Every validator holds the whole state and applies every batch itself.

The bridge vault on Arbitrum One holds the USDC that backs every account's balance.

The path of an operation

From an operation to a final blockA signed operation is accepted by the network and passed to every validator. A height's leader includes it in its block. Heights are grouped into batches, and the validators agree on each batch as a whole. A block is final once the validators certify it. Every validator then applies the batch in the same order, so every validator holds the same state.Acceptedpassed to every validatorIn a blockthe height's leaderIn a batcha run of heightsFinalthe validators certify itApplied by every validator, in the same orderVordCore · the same state on every validator
From an operation to a final block
  1. Intake. A public interface checks the signature, the format and the rules it can judge at once (a known pair, a price inside the band, the account's open-order count). A refusal answers immediately with a reason code. An accepted operation answers 202 submitted: it has been accepted, not yet applied.
  2. Forwarding. The accepted operation is passed to every validator over the validator network. There is no public peer-to-peer mempool; any validator that leads a height can include it.
  3. Ordering. The leader of a height puts operations in its block. Heights are grouped into batches, and the validators agree on each batch as a whole.
  4. Application. Every validator applies the batch: VordCore matches orders, checks margin, settles funding, runs liquidations. Matching and risk work run at the batch boundary, so every validator reaches the same state.
  5. Reading back. The result is visible in the committed state (open orders, positions, balances) and in the trading records. Confirm a write by reading it back, never by the 202 alone.

Committed state and records

Two kinds of data come out of the chain:

  • Committed state — balances, positions, open orders, agents, sessions. It is what every validator holds; reads that serve it say "source": "committed_state".
  • Trading records — what happened, per height: orders placed and closed, fills, funding payments, liquidations, agent refusals. Every node that covers a height holds the same records for it. A height a node does not cover is unknown, never "nothing happened". See State and records.

Agreed facts

GET /truth/v1 answers only what several validators agree on: the chain id, the genesis, the finalized height, the rules in force, and whether trading, deposits, the EVM and agent rules are on. If the sources disagree or are stale it says so ("ok": false with a reason) instead of guessing. Every live value on this site that says "right now" is read from there.

Network facts last checked against the network 2026-10-22 13:00:37 UTC · mainnet spec v28 · testnet spec v8

On this page