The fastest way to plug a desk into EPEX SPOT.
On your hardware. On your terms.
EPEX SPOT intraday is a delta stream. Six to seven million updates per day, per delivery area — twenty million across three areas, forty-plus across central-western Europe. A typical Java stack can't keep up.
Sub-millisecond inter-arrival at peak. 6.5M updates per day per delivery area. The book never stops moving.
Applies each delta in ~15μs. Hundreds of times faster than the inter-arrival window. Your strategy sees the book as it changes.
5–10ms per delta. The market sends another ten before you've finished applying the first. Your strategy is always behind.
The desks that move first win. The desks that babysit lose.
Your trading stack connects to one Voltnir node over REST or gRPC. Voltnir maintains the M7 session — both protocol versions — and handles the order books, session state, reconnects, and gap detection. Multiple clients can share the same connection. You send orders, you read the book, you trade.
The protocol is our problem, not yours.
Voltnir is delivered as software you deploy on your own infrastructure — your servers, your data center, your cloud tenant. We don't host your order flow. We don't see your positions. We don't have access to your book.
voltnir-1.0.0-linux-x86_64Runs on Ubuntu 18.04+, RHEL 7+, Alpine, any Linux kernel 4.15+. One file. No installer.
voltnir-license.signedBound to your EPEX SPOT user_id. Issued by you, signed by us, verified by the binary. Delivered through your customer portal.
Run Voltnir on an air-gapped network with one EPEX SPOT-only egress rule. We invite you to verify.
You bring: a Linux server, EPEX SPOT credentials, network access. We bring everything else.
You own the deployment. You own the data. You own the off-switch.
Voltnir's virtual members let one EPEX SPOT membership host trading for multiple legal entities — your own subsidiaries, your asset-operator clients, the battery operator next door who needs balancing but can't justify a membership of their own.
Each entity gets its own member identity, its own MW limit enforced before any order reaches the market, and per-action attribution to the user who placed it. Users hold composable permissions — submit, modify, cancel, adjust limits, read books, export audit. Your seat. Their orders. Clean books.
Battery operators. Small renewables shops. Balancing groups without their own seat. Isolated by member. Attributable per action. Billable per month.
Turn your EPEX membership from a cost center into a revenue line.
The asset owner provides assets and strategy intent. You provide execution, the seat, and a defensible audit trail attributed per user, per member.
Higher-margin than brokerage. Provable on every order.
One Voltnir node. One audit log. Multiple legal entities, each with its own MW limit, its own users, its own attribution stream.
One infrastructure footprint instead of many. One console for risk and compliance.
Your membership. Their orders. Your margin.
Compliance teams ask “who did what, when, and on whose seat?” Voltnir answers in one query.
Voltnir writes a structured audit record for every order and trade that crosses the platform — user, virtual member, EPEX user_id, timestamp to the millisecond, before-and-after state, result. Stored on your infrastructure. Queryable from yours.
When a regulator, an external auditor, or your head of risk asks who did what and on whose seat, the answer is one query. Filter by user, member, event type, or time range. Export as CSV or JSON. Stand up to scrutiny without a forensic project.
One query. No archaeology.
What happened on the desk at 14:32 yesterday? Pull the trace, replay the sequence, find the cause. Every order that hit the market has a verifiable origin and a recoverable before-and-after.
No more “I think it was Jan.”
Multi-tenant attribution travels with every action. Prove which virtual member placed which order, prove which seat submitted which trade, prove it down to the user who clicked Submit. Bill cleanly. Defend disputes.
Attribution per action. Always.
GET /api/v1/audit ?from=2026-05-15T14:00:00Z &to=2026-05-15T15:00:00Z &user=j.koenig &event=order.modify &limit=100 Authorization: Bearer ${VOLTNIR_TOKEN}
[
{
"ts": "2026-05-15T14:07:42.118Z",
"event": "order.modify",
"user": "j.koenig",
"member": "NL-BATTERY",
"epex_user": "EPEX-NL-04",
"order_id": "ord_2c91...",
"field": "price",
"before": 41.50,
"after": 42.10,
"result": "accepted"
},
{
"ts": "2026-05-15T14:14:09.882Z",
"event": "order.modify",
"user": "j.koenig",
"member": "NL-BATTERY",
"epex_user": "EPEX-NL-04",
"order_id": "ord_2c91...",
"field": "qty",
"before": 1.0,
"after": 1.5,
"result": "accepted"
},
{
"ts": "2026-05-15T14:18:55.301Z",
"event": "order.modify",
"user": "j.koenig",
"member": "NL-BATTERY",
"epex_user": "EPEX-NL-04",
"order_id": "ord_4a01...",
"field": "qty",
"before": 2.0,
"after": 5.5,
"result": "rejected",
"reason": "mw_limit_exceeded"
},
{
"ts": "2026-05-15T14:24:18.660Z",
"event": "order.modify",
"user": "j.koenig",
"member": "DE-RENEWABLES",
"epex_user": "EPEX-DE-02",
"order_id": "ord_7b3e...",
"field": "price",
"before": 38.75,
"after": 39.40,
"result": "accepted"
},
{
"ts": "2026-05-15T14:32:17.488Z",
"event": "order.modify",
"user": "j.koenig",
"member": "NL-BATTERY",
"epex_user": "EPEX-NL-04",
"order_id": "ord_8a3f...",
"field": "price",
"before": 42.50,
"after": 43.25,
"result": "accepted"
},
{
"ts": "2026-05-15T14:41:02.117Z",
"event": "order.modify",
"user": "j.koenig",
"member": "INTERNAL-DESK",
"epex_user": "EPEX-FR-09",
"order_id": "ord_d105...",
"field": "price",
"before": 51.10,
"after": 50.80,
"result": "accepted"
},
{
"ts": "2026-05-15T14:53:46.954Z",
"event": "order.modify",
"user": "j.koenig",
"member": "NL-BATTERY",
"epex_user": "EPEX-NL-04",
"order_id": "ord_e22b...",
"field": "qty",
"before": 3.0,
"after": 2.5,
"result": "accepted"
}
]The audit log captures actions, not intent. Your strategy, your model weights, your PnL, your forecasts — none of it leaves your box.
One database. One endpoint. Your auditor’s job, done.
If you've built your strategy, you don't want a vendor SDK wrapped around your trading logic. You want a market access layer you can plug in and forget. Voltnir gives you that — orders, fills, positions, kill-switch, audit — through one versioned contract, served two ways.
REST is the on-ramp. JSON over HTTPS, no protobuf compiler, no streaming client to configure. Prove the workflow in a Python script over lunch, get it past your risk team by Friday. Every endpoint here mirrors a gRPC RPC exactly — same fields, same units, same permission gates. The migration is a transport swap, not a rewrite.
Prototype in an afternoon.
gRPC is where production Voltnir lives. Server-streamed order book deltas the moment the exchange publishes them. Server-streamed fills the moment they happen. HTTP/2, protobuf-framed, schema-typed on both ends. No polling. No webhook server to babysit. No JSON parser eating microseconds in your hot path.
Wire speed. No exceptions.
One .proto file is the contract. Run protoc against it and you have a typed client in any language gRPC supports — your IDE catches the bug your tests would have missed. Python SDK ships pre-built today, JavaScript and Go next. Everyone else: thirty seconds with the compiler and you're talking to Voltnir.
The .proto is the contract.
Numbers behave like numbers. Every price, quantity, and limit moves as a fixed-point integer — no floats anywhere in the API, no rounding ghosts in your PnL. Money math behaves like money math.
Permissions are enforced at the boundary, not in your client. A user with create_order but not delete_order cannot cancel orders. Not their own, not anyone's. API keys are SHA-256 hashed at rest and shown exactly once at creation — lose one, you rotate, you do not recover. One call to the kill-switch cancels every resting order on your seat: no undo, no ambiguity, no support ticket.
No webhooks. No surprise breaking changes. The API does what it says.
POST /api/v1/order Authorization: Bearer ${VOLTNIR_TOKEN} Content-Type: application/json { "side": "BUY", "price": 5000, "quantity": 1000, "delivery_area_id": "10YNL----------L", "product": "H", "delivery_start": "2026-05-15T22:00:00Z", "v_member_short_id":"NL-BATTERY" } // → 201 Created // {"client_order_id":"550e...","state":"ACTIVE","reason":null}
from voltnir import VoltClient client = VoltClient( host="voltnir.local:3443", api_key=os.environ["VOLTNIR_TOKEN"], ) result = client.submit_order( side="BUY", price=5000, quantity=1000, delivery_area_id="10YNL----------L", product="H", delivery_start="2026-05-15T22:00:00Z", v_member_short_id="NL-BATTERY", ) # → state=ACTIVE id=550e...
One contract. REST to prototype. gRPC to ship.
Voltnir ships with a complete trading terminal. Live order book, order entry with pre-flight risk checks, position and P&L on one screen. Built on the same API any client would use — every change we make to it, our pilot customer trades on it the next day.
Your seat. Our desk.
Voltnir is the trading infrastructure we wanted when we were on the desk and couldn't get it. No JVM. No GC pauses in the hot path. No “we'll fix it in the next major version.” The product is the engineering, and the engineering is the product.
We built it for ourselves first. We run it ourselves today. We ship it because it works.
Most trading infrastructure charges by user count, message volume, or some combination of both. Voltnir doesn't. You pay once per EPEX SPOT license you connect to the platform — flat, predictable, and the same whether you run one virtual member or ten.
Trade through the terminal. Ship every fix for free.
The full surface. Same binary. A human on Signal.
One price per license. One product to license. No seat math.
Voltnir takes minutes to deploy. One static binary, one signed license file, one outbound connection to EPEX. The hardest part is converting your EPEX SPOT p12 certificate to key + pem — we walk you through it on the call.