Publish a Market Data Feed on
DoubleZero Edge

DoubleZero Edge is a low-latency multicast fabric for market data. If you operate a trading venue — a centralized exchange, an onchain order book, a prediction market, or anything else with a live stream of order events — you can stand up a feed publisher that broadcasts your order book and trade events across DoubleZero Edge in a compact binary format. Subscribers receive your feed with measurable, repeatable latency anywhere DoubleZero Edge reaches.

This page walks through what’s involved. To get access to the wire format spec and the private GitHub repository, use the request form at the bottom.

Two ways to publish

• You run the publisher. Your team builds and operates the publisher on your own infrastructure close to your matching engine. The multicast group can be permissioned — subscribers are explicitly authorized through Edge, and you control that list.
• A third party runs the publisher. A specialized publisher reads from your venue’s public data surface (REST/WebSocket API, a gossip node, onchain events) and operates the feed independently. The multicast group is open, and multiple publishers can emit the same feed in parallel. The protocol measures publisher performance and rewards the fastest, so subscribers always receive the best available access to your data.

The technical connection to DoubleZero Edge is identical in both cases. The wire format, multicast group setup, and doublezerod integration are the same regardless of who operates the publisher.

The process

1. Classify your venue

Before writing any code, answer four questions:

• Where does matching happen? Identify the cloud region (or data center) where your matching engine lives. This determines where your publisher needs to run. Don’t rely on latency probes against your public API hostname — most trading APIs are CDN-fronted, so probes measure CDN edge distance rather than matching-engine distance. Use first-party signals: your own infrastructure documentation, region-specific gateway hostnames, or a conversation with your infra team.
• What’s your data path? First-party REST/WebSocket API, a private feed, P2P gossip, or onchain events — each implies a different ingestion approach and a different host shape.
• What’s your instrument universe? How many products do you list? What does an instrument definition look like (symbol, tick size, lot size, price and quantity precision)? If you list hundreds or thousands of markets, define a selection policy before you start.
• Are there redistribution constraints? If your data is licensed or regulated, settle terms before publishing.

2. Pick a publisher host

Run the publisher as close to your matching engine as possible — same cloud region at minimum, same availability zone if you can. Size the host to your workload:

• API-based publishers (REST/WebSocket) are CPU-bound by parsing and encoding. A small compute instance is sufficient.
• Node-based publishers (a chain node, a gossip node) are storage-bound and need disk headroom for the node data plus a pruning strategy.

Confirm that a DoubleZero Edge attachment point is reachable from your chosen region before you provision.

3. Connect to DoubleZero Edge

Install the doublezerod daemon on your publisher host and configure:

• A GRE tunnel to the assigned DoubleZero device
• A BGP session over that tunnel
• A multicast group route for your feed

Full connection guides are available in the DoubleZero documentation. The publisher uses the same attachment mechanism as any other DoubleZero participant.

4. Map your data to the wire format

Walk your venue’s native data model against the DZ-TOB message types defined in the spec:

• Best-bid-and-offer updates → Quote frames
• Fills → Trade frames
• Instrument metadata → InstrumentDefinition frames on the refdata channel

Get price and quantity exponents right before you emit a single Quote. This is the most common source of downstream bugs. A subscriber that decodes a quantity with the wrong exponent gets silently wrong data, and the failure is hard to spot until it matters.

For venues with large instrument universes, define a selection policy at this stage: which markets to publish, how to rank them, and how to handle new listings and delistings without disrupting existing subscribers.

5. Build the publisher

With the data model confirmed, implement the publisher:

• Ingest from your venue. Handle reconnects, backoff, rate limits, and snapshot recovery from the start — don’t defer this to production
• Maintain per-instrument book state in memory, applying incremental updates from the ingestion layer.
• Emit frames in the correct order: a Startup control frame first, then InstrumentDefinition frames on the refdata channel, then Quote and Trade frames on the marketdata channel as the book changes, and Heartbeat frames during quiet periods.
• Claim a Source ID via a pull request against the spec repository before any frames go out on a real feed. One Source ID per venue.
• Test against the sample subscriber included in the spec repository. The Wireshark Lua dissector is useful for packet-level verification.

Start with top-of-book. Full depth-of-book is a separate frame family in the same spec and can be layered on once top-of-book is stable.

6. Operate

A publisher is a production service. Build it that way from day one:

• Process-managed (e.g. systemd) with automatic restart on failure
• Prometheus-instrumented with the standard ingress, egress, book, and refdata metric set defined in the spec — metric names are normative so dashboards and alerts work across venues without per-venue configuration
• Refdata-refreshed on a schedule so new listings appear without a publisher restart and late-joining subscribers can recover instrument definitions

Get the spec

The wire format spec is publicly available. Access the repository → and follow section 4 to map your data to the wire format.