Skip to content

What is Virtufin?

Virtufin is an open, event-driven platform for building real-time trading systems. The platform replaces the typical "vendor stack plus glue" pattern with a small set of services that talk gRPC and Dapr to each other, governed by a published specification.

The problem

A modern quant team is usually running something like this:

  • A market-data vendor (websocket, proprietary protocol, finicky reconnect)
  • A homegrown order router (REST or FIX, depending on the broker)
  • A strategy runtime in a single language (Python, often)
  • A backtesting rig that re-implements half of the above
  • A monitoring layer that knows all of this by name

Each piece is its own product. The contract between them is "ask the senior dev". Replacing any piece is a six-month project. A new strategy language means a new execution path. A new exchange means a new data adapter, a new backtest loop, a new monitoring graph.

The answer

Virtufin is built around three ideas:

  1. One gateway, one protocol. Every backend service speaks gRPC to the API gateway. Clients — C#, Python, TypeScript, Rust, Scala, Dart, OCaml, WasmCloud — talk to the same gateway. No bespoke REST layers per service.

  2. Workers are first-class plugins. A worker is a binary (a .NET DLL, a Python script, a Rust .so, a C++ shared library) that the WorkManager loads and runs. In-process for the .NET case (sub-µs latency), or out-of-process for the Python / native cases. The DevKit standardises the wire protocol so writing a worker is the same in every language.

  3. Events are the source of truth. All inter-service traffic flows through Dapr pub/sub on CloudEvents 1.0 envelopes. The lane and scenario naming scheme gives the same event stream a production address, a backtest address, and a per-selector address without any service-level change.

Principles

  • Open spec first. Every contract has a page in virtufin-openspec before any code lands.
  • Polyglot where it makes sense. A worker is a binary. The platform is language-agnostic. SDKs are convenience.
  • AOT-native. The .NET services are NativeAOT-compiled. No JIT, no warm-up, no surprises in production.
  • In-process where it matters. .NET DLL workers run inside the WorkManager process via libhostfxr and an AssemblyLoadContext. Sub-µs per-call latency, single CoreCLR, no IPC.
  • No magic. The configuration is in versions.env, the services are in services.json, the topics are in Configuration/Topics.cs. No Spring-style auto-discovery.
  • Boring infra. Dapr for pub/sub, state, and service invocation. Kubernetes or docker compose. NATS or Redis for the broker. No bespoke consensus layer.

Where the open spec lives

The single source of truth for the platform is virtufin-openspec (also rendered at specs.docs.virtufin.com). Every cross-cutting decision — pub/sub lane naming, state key prefixes, scenario registry semantics, worker wire protocol — has a spec page. The services implement the spec; they do not invent it.