The BDN fan-out path is not Solana-specific. Solana is the chain that is live today, but the transaction track header carries a chain short-id, and every chain that the FirstByte BDN knows about has its own MoQT namespace. This page explains the registry behind the Multichain console screen, what a short-id is, and what changes when you submit on a namespace other than Solana’s.

​
The chain registry and what a short-id is

The registry is the table named bdn.chains on the Multichain screen. It is read by chains.list, and each row carries: A short-id is a one-byte routing prefix. It is the only chain discriminator that travels with a transaction through fan-out. Relays and mod_bdn route and de-duplicate on it rather than on the namespace string, so the prefix stays cheap to parse on the hot path. Solana is 0x01:
The dedup_key is per chain as well — for Solana it is the first 64 bytes of the signature. De-duplication happens within a chain’s namespace, so two chains can never collide on a key.

​
Per-chain MoQT namespaces

Each registered chain gets its own namespace, and the transaction track lives under it as bdn/<chain>/tx. Solana occupies the unprefixed bdn/tx, which is why the existing Solana wire model (sol/feed/mainnet tracks, /bdn/submit, /tpu) reads the way it does; other chains are namespaced explicitly, for example bdn/eth/tx. Namespacing per chain gives you track isolation: a subscriber on one chain’s transaction track never receives another chain’s traffic, and relay-token namespace scope is granted per chain. A token scoped to bdn/tx does not grant publish or subscribe on bdn/eth/tx. See Authentication for how namespace claims are carried in a relay token. The console summarises these two primitives under Per-chain capabilities, because they are what mod_bdn applies to every fanned-out transaction regardless of chain:
  • Short-id chain registry — the one-byte routing prefix on every fanned-out tx.
  • Per-chain MoQT namespaces — bdn/<chain>/tx track isolation.

​
Registering a chain

Registration adds a row to bdn.chains. It binds a short-id to a namespace:
Both arguments matter and neither is inferred:
  • short_id — the byte that will be stamped into the chain field of the track header for this chain. It must not already be taken by another row in the registry; the registry is a bijection between short-id and namespace.
  • ns — the MoQT namespace whose tx track will carry this chain’s transactions.
Registration is a platform-level operation. It makes the chain known — it appears in chains.list, with its short-id and namespace visible — but it does not by itself make the chain usable by your organisation. On the Multichain screen, a registered-but-not-yet-enabled chain renders dimmed with a Not enabled pill.

​
Enabling a chain for an organisation

Enablement is a separate, per-organisation step from registration. The status field that chains.list returns is scoped to the calling org:
  • live — the chain is enabled for this organisation. The row renders at full opacity with a live Live pill, and it counts toward the N live badge in the page header.
  • anything else — the chain is registered in bdn.chains but not enabled for this organisation, and the console labels it Not enabled.
So two organisations reading the same registry can see the same short-id and namespace for a chain while disagreeing on whether it is live. The registry is global; the enablement is yours. Solana is the chain enabled today; the other rows in the table are registered and awaiting per-org enablement.

​
Submitting on a non-Solana chain

The submit path does not change shape when you move off Solana. What changes is which namespace you address and which short-id the header carries:
  1. Hold a relay token scoped to that chain’s namespace. A token whose ns claim covers bdn/tx is a Solana token. For bdn/eth/tx you need a token minted with that namespace in scope.
  2. Publish to the chain’s tx track under its namespace — bdn/<chain>/tx — rather than to Solana’s bdn/tx.
  3. Stamp the registered short-id in the chain field of the track header. mod_bdn routes fan-out on this byte, and de-duplicates the transaction using that chain’s dedup_key rule within that chain’s namespace.
The Solana-specific pieces of the existing path do not generalise. /tpu is Solana’s leader-facing submission surface and the sol/feed/mainnet tracks are Solana’s feed; neither has a counterpart on another namespace simply because that namespace is registered. Use the chain’s own bdn/<chain>/tx track as the submit surface. If a chain shows Not enabled for your organisation, publishes into its namespace are outside your relay token’s namespace scope — enable the chain for the org first.