# Solana BDN over QUIC

> Get low-latency Solana data in and land transactions fast. Feeds arrive over QUIC. The BDN fans transactions across the edge mesh to validator TPUs.

<img src="/images/diagrams/crypto.png" alt="crypto data flow" />

Get low-latency [Solana](https://solana.com) 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](https://datatracker.ietf.org/wg/moq/about/)
   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.

> **NOTE:**
> **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_connect/moqt`) to subscribe to feed tracks. A dedicated typed
> `Crypto` client is a **Preview** — see [SDK methods](./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:

| Track                               | Payload fields                              | Cadence |
| ----------------------------------- | ------------------------------------------- | ------- |
| `sol/feed/mainnet/slots`            | `{ slot }`                                  | push, every slot |
| `sol/feed/mainnet/blockhash`        | `{ slot, blockhash, lastValidBlockHeight }` | push, every N slots |
| `sol/feed/mainnet/priorityFee`      | `{ slot, p50, max }`                        | poll, every N slots |

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](./cookbook#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:

| Route          | Path           | Behaviour |
| -------------- | -------------- | --------- |
| **BDN fan-out**| `POST /bdn/submit?leader=auto` | Ingests once, deduplicates, and fans the tx across **all edges**. Each edge lands it on its nearby leaders. |
| **Direct TPU** | `POST /tpu?host=auto`          | Sends the tx straight to the **current + next leader** TPUs from this node. There is no fan-out. |

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

| Concern             | How the BDN handles it                                       |
| ------------------- | ----------------------------------------------------------- |
| **Feed delivery**   | MoQT frame track. The relay mesh pushes each object on a QUIC stream and fans it out. Late joiners get the newest object first. |
| **Tx delivery**     | Raw QUIC to the validator TPU with `ALPN solana-tpu`. Each connection uses an **ephemeral ed25519** client identity. |
| **Dedup**           | A short-id cache keyed on the 64-byte signature suppresses duplicate lands across the mesh. Its `dedup_ttl_secs` is configurable. |
| **Leader fan-out**  | `fanout_leaders` (1–4) sets how many upcoming leaders the BDN lands a tx on at once. |
| **Reliability**     | The transaction is data: a frame, not a media stream. There is no transcode and no loss-concealment. The tx lands verbatim, or it does not land. |

## 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](/concepts/architecture).
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](/concepts/architecture) 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.

> **TIP:**
> 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](./sdk-methods)** — Subscribe to feeds with the MoQT client. Read about the Preview typed
    `Crypto` surface.
  - **[Cookbook](./cookbook)** — Do short tasks: subscribe to a track, submit a tx, target a leader, and
    tune dedup.
  - **[Recipes](./recipes)** — Build end-to-end examples: a feed-driven submitter and a private-feed
    consumer.