# Multichain: chain registry and short-id routing

> How the BDN chain registry maps a one-byte short-id to a per-chain MoQT namespace, how chains are registered and enabled per organisation, and what a non-Solana submit path looks like.

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:

| Field      | Meaning                                                                 |
| ---------- | ----------------------------------------------------------------------- |
| `name`     | Human-readable chain name shown in the console.                         |
| `shortId`  | The compact routing prefix stamped on every fanned-out transaction.     |
| `ns`       | The MoQT namespace that carries that chain's transaction track.         |
| `status`   | `live` (enabled for this org) or not-enabled.                           |
| `note`     | Free-form registry note, rendered in the **Notes** column.              |

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`:

```json
// bdn/tx track header
{
  "chain": "0x01",          // short-id → solana
  "ns": "bdn/tx",
  "track": "mainnet",
  "dedup_key": "sig[0:64]"
}
```

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](/concepts/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:

```python
register_chain(short_id=0x02, ns="bdn/eth/tx")
```

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.

## Related

- [Authentication](/concepts/authentication) — relay tokens and namespace scope
- [Telemetry](/platform/telemetry) — metrics and traces emitted per namespace