vCryptoNet


2.6µs Median Latency from NIC Hardware RX Timestamp to Decrypted Market Data in Shared Memory


Download & Run Benchmark
Schedule Free Setup call (30 min)

vCryptoNet is a C++/DPDK crypto market data engine with a custom, purpose-built TCP/TLS/WebSocket stack, delivering decrypted market data from hardware RX timestamp to shared memory in 2.6µs median latency while scaling to 5,000 concurrent feeds per CPU.

Problem

• Kernel networking adds tens of microseconds.

• Memory footprint limits scalability.

• Large numbers of redundant feeds add network queuing latency.

• Exchange TLS/WS endpoints vary in load and latency over time by more than 200µs

Introducing vCryptoNet

Instead of using Linux networking plus existing TLS and WebSocket libraries, vCryptoNet implements:

TLS, TCP, WebSocket, Smart arbitration engine, Connection scoring and auto-recycling, directly on DPDK.   

The output is simply decrypted, arbitrated market data written into shared memory.

Why is it Faster?


Our implementation of network components exploit properties about crypto market data that generic network stacks can’t.



Ultra-Lean Memory & CPU


Tiny Footprint          Uses only 42 bytes per connection, compared to several kilobytes in OpenSSL.

Zero-Copy Architecture 
Data flows straight across all network layers without buffering.                       

Zero Heap Allocations 
Unlike standard tools (OpenSSL, WolfSSL) that pause to allocate memory in the hot path, vCryptoNet uses zero heap allocations.     

Hot CPU Cache      During idle intervals, threads loop synthetic packets to keep all relevant code and data hot in L1d/i and L2 caches.



Custom TLS Network Stack



Custom ENA Driver 
Features a heavily customized ENA poll-mode driver in DPDK tuned specifically for market data arbitration.

No Server Delays: Our TCP stack never slows down server pacing. It can even ACK a lost packet if the data was already received over a redundant connection.

Forces Low Latency: Tricks crypto exchanges into behaving as if TCP_NODELAY is enabled, significantly improving tail latency during heavy market spikes.

Stripped-Down Logic: Bypasses kernel checks, no saving packets for retransmission, no congestion window tracking, and no wasted clock cycles.




Smart  Connection Management



Smart Connection Recycling                Scores and prioritizes every connection, automatically replacing slow links with IPs predicted to be faster.

Lightning-Fast Arb.  Processes losing arbitrage packets 10x to 100x faster than generic TLS/TCP stacks.

The Compounded Effect: During high-volume trading across up to 5,000 channels, microsecond advantages compound, while standard libraries queue up and lag, vCryptoNet stays real-time.

Benchmarks

All benchmarks were performed on AWS instances of type c7i.metal-24xl (Intel Xeon Platinum 8488C, 3.2 GHz, 192 GB), located at availability zone ID: apne1-az4. Operating system: Linux Ubuntu 22.04 
                                                                              
Unless otherwise stated, each implementation does 20x connection arbitration against btcusdt@trade, Binance.                                                                          

Each implementation, the first time it sees a trade ID across its connections, writes down the trade ID and the receive timestamp for it as soon as the decrypted market data is available. 
                          
The implementations are run simultaneously from their own dedicated CPUs. Each implementation’s best timestamp for each trade ID are compared to produce the tables.

Internal Latency

Configuration: 20x arbitration against btcusdt@trade, Binance (approx. 25 packets per second each).

P50 (µs) P95 (µs) P99 (µs)
vCryptoNet 2.63 7.49 8.52
WebSocket++ 82.65 974.18 1295.04
LibWebSockets 89.72 794.45 879.79
Boost.Beast 86.56 244.20 305.88
FastWS 116.69 596.37 39677.64
CppServer 79.54 177.78 204.95

NIC Hardware RX timestamp → Decrypted Market Data

Exchange-to-Decrypted Market Data


Crypto exchanges, by nature of the serial TCP/TLS market data distribution, show large latency jitter across parallel connections. Hence more connections statistically improve the latency at which prices can be processed. Increasing the number of connections beyond a certain limit will have negative effects, as delays in various queues start overshadowing the latency gains from arbitration.                                                                          
The “@trade” market data events from Binance contain a JSON field “E” which is filled by the exchange when the event is created and pushed downstream for mass distribution

P50 (µs) P95 (µs) P99 (µs)
vCryptoNet 951.2 1,255.7 1,307.9
LibWebSockets 1,122.4 1,806.3 1,963.2
WebSocket++ 1,152.1 1,911.1 2,318.3

Binance ‘E’ timestamp → Decrypted Market Data

Percentage of Trades Received Within Exchange Latency

Distribution of Exchange-to-Engine Latencies

Other Implementations


Other implementations have internal latency profiles similar to LWS and WebSocket++, with the
exception of FastWS which displays larger tails.                                                                                                                                                               
The library versions tested are:
• LibWebSockets 4.3.10: https://libwebsockets.org/
• WebSocket++ 0.8.2: https://github.com/zaphoyd/websocketpp
• Boost.Beast 1.83: https://www.boost.org/doc/libs/latest/libs/beast/doc/html/index.html
• CppServer 1.0.6.0: https://github.com/chronoxor/CppServer
• FastWS 1.0.3: https://github.com/dgrr/fastws                                                                                                                                                            
Note that for clarity, vCryptoNet was ommitted from this KDE plot due to its very sharp peak at 2.6µs

Download & Run Benchmark
Schedule Free Setup call (30 min)