crypto data flow

Crypto BDN data flow — feeds in over MoQT, transactions out over QUIC to validator TPUs.

Get low-latency Solana data in and land your transactions fast. Subscribe to slot, blockhash, and priority-fee feeds. The edge pushes each update the instant it sees it. Send a signed transaction to a block-dissemination network (BDN). The BDN fans the transaction out and lands it directly on the leader validators’ TPU (Transaction Processing Unit). The modality does two jobs:
  1. Feeds in — the edge ingests low-latency Solana data (slots, recent blockhash, priority fees) and republishes it as named MoQT tracks. Traders subscribe over QUIC. They read each update the moment the relay fans it out.
  2. Transactions out — you send a signed transaction to the BDN. The BDN deduplicates the transaction and fans it out across the edge mesh. It lands the transaction directly on the current and next leader validators’ TPU over Solana’s native QUIC protocol.
Everything runs over QUIC and nothing else. HTTP/3 carries the request/response calls. MoQT carries the feed tracks. Raw QUIC with ALPN solana-tpu carries the leg out to validators. There is no gRPC and no WebSocket on the client edge. The service refuses clients that cannot negotiate QUIC. There is no TCP fallback.
No typed SDK ships for crypto yet. Today you use the BDN in two ways: the QUIC submit/feeds HTTP/3 API (any HTTP/3 client), and the raw MoQT client (@clutchcall/sdk/moqt) to subscribe to feed tracks. A dedicated typed Crypto client is a Preview — see SDK methods. Everything below describes what runs today.

​
When to use it

Land transactions faster

Submit a signed Solana tx once. The BDN fans it out and lands it on several upcoming leaders’ TPUs in parallel, not through a single RPC hop.

Low-latency trader feeds

Subscribe to slot / blockhash / priority-fee tracks over QUIC. The edge pushes each update the instant it sees it. You do not poll an RPC node.

Bring your own ingest

Set the ingest to your own gossip/Geyser endpoint. This publishes a private feed track scoped to your organization.

Co-located edge mesh

A root ingests and fans out to edge relays near the validators that they land on. This shortens the network path between you and the leader.

​
Wire model

The BDN is a small set of MoQT track namespaces plus two HTTP/3 submit paths.

​
Feed tracks (BDN → you)

Feeds are ordinary MoQT frame tracks. Each track is a namespace + name that carries opaque binary objects. The relay mesh fans out these objects. The public Solana mainnet feed lives under the sol/feed/mainnet namespace: The BDN publishes a private feed (your own ingest endpoint) under sol/feed/<orgId>/…. Only your organization can see it. You subscribe to any of these tracks with the raw MoQT client — see Subscribe to a feed track.

​
Submit paths (you → BDN → validators)

You deliver a signed transaction over HTTP/3 with the raw tx as an application/octet-stream body. There are two routes: For both routes, leader=auto / host=auto resolves the leader schedule automatically. Pass an explicit host:port to target a specific validator TPU. The first 64 bytes of the transaction are its Solana signature. The BDN uses them as its dedup key. Thus, if you re-submit the same tx across edges, it lands at most once per leader.

​
Lanes & QoS

​
Finding the endpoint

Clients find the QUIC port through a DNS HTTPS resource record on the crypto host (alpn=h3, with the QUIC port in the record). The rest of the platform uses the same mechanism for HTTP/3 endpoint discovery. You discover feed tracks when you subscribe to a namespace prefix. The relay holds the subscribe even for a track that is not announced yet. Thus you can subscribe to a private feed before your ingest publishes its first slot.

​
How it works

The BDN runs on the same shard-per-core engine as every other modality. You inherit its kernel-bypass data path. Thus your feeds arrive the instant the edge sees them, and your transactions leave the box with minimal overhead.
1

Ingest (root)

The root node subscribes to Solana data on a single shard. The source is a public RPC slotSubscribe or your own gossip/Geyser endpoint. The root stamps each update into a MoQT frame object.
2

Fan-out (relay mesh)

The relay mesh fans each feed object and each submitted tx to every subscribed edge. It uses one QUIC connection per peer. Cross-shard hand-off uses lock-free mcache / dcache rings. Thus a feed never crosses a lock to reach a subscriber.
3

Land (edge → TPU)

Each edge resolves the leader schedule (getLeaderSchedule). It opens a raw QUIC connection to the leaders’ TPU endpoints and writes the transaction. The NIC fast path is kernel-bypass, with per-core flow steering and zero-copy buffers. Thus the tx leaves the box with minimal kernel overhead.
The edge sits between you and the validator. Thus the BDN can land a tx on the next leader before that leader becomes current. It moves ahead of the slot boundary instead of racing it. This is the benefit of fanout_leaders > 1.

​
Next

SDK methods

Subscribe to feeds with the MoQT client. Read about the Preview typed Crypto surface.

Cookbook

Do short tasks: subscribe to a track, submit a tx, target a leader, and tune dedup.

Recipes

Build end-to-end examples: a feed-driven submitter and a private-feed consumer.