# Crypto Console

> Operate the BDN: watch feeds and the network, submit transactions, build MEV bundles, and track landings.

The Crypto Console is the ready-made web app that operates your FirstByte
block-dissemination network (BDN). You do not write code. From one place you
can:

- Watch live feeds and the edge mesh.
- Send signed transactions to the BDN to land.
- Build MEV bundles.
- Trace every landing.

The console is for traders, searchers, and infrastructure operators who want to
see and operate the BDN directly.

## What's in the console

  - **Overview** — This screen shows a KPI strip, a land-rate chart, a BDN topology mini-map,
    and a submit quickstart with the live landing stream.
  - **BDN network** — This screen shows the root and edge star topology, per-edge health, a
    cluster selector, the node role (root or edge), and dedup-cache tuning.
  - **TPU landing** — This screen shows the live leader schedule, per-leader land success and
    latency, fan-out breadth, and manual or auto landing configuration.
  - **Submit** — Paste a signed transaction. Land it through BDN fan-out or direct TPU. The
    screen shows a live result and a copy-ready request.
  - **Data feeds** — Monitor the slots, blockhash, and priorityFee tracks. Tune your feed
    cadence. Use your own Geyser endpoint.
  - **MEV bundles** — Build a bundle of up to five ordered, atomic transactions with tip routing.
    Track recent bundle landings.
  - **Transactions** — This screen shows a searchable ledger of the ingest → fan-out → land
    pipeline. It has a per-transaction detail drawer and CSV export.
  - **Analytics** — This screen shows land rate over time, latency percentiles, fan-out volume,
    dedup ratio, and per-leader and per-region breakdowns.
  - **Multichain** — This screen shows the short-id chain registry and per-chain namespaces.
    Solana is live today. Other chains are registered per organization.
  - **API keys** — This screen shows QUIC endpoints, API keys (scoped to bdn, tpu, feeds, or
    read), and SDK snippets.
  - **Usage & billing** — This screen shows metered transport counts (tx sent, bytes, fan-out,
    landed), live transport metrics, and recent errors.

> **NOTE:**
> Some screens are **organization-scoped**. Private Geyser feeds, per-organization
> feed cadence, and API-key creation require that you are **signed in** with an
> active organization. If you are not signed in, those panels show a sign-in
> prompt.

## Get oriented on the Overview

  1. **Open the Overview**
The **Overview** header shows the network and cluster (e.g. `mainnet`). The
    KPI strip across the top shows a summary of current BDN health.
  2. **Pick a time range**
Use the range selector (**15m / 1h / 24h**) in the header. It sets the
    window for the **Land rate** chart. The chart plots BDN fan-out and direct
    TPU landings as a percentage of submitted transactions.
  3. **Watch recent landings**
The **Recent landings** panel streams live results. Each row shows a
    `landed` / `dropped` pill, the signature, the landing leader and slot, the
    fan-out edge count, and the land latency. Click **View ledger** to open the
    full **Transactions** screen.
  4. **Refresh or jump to submit**
Click **Refresh** to get the latest statistics. Click **Submit tx** to open
    the submit console. The **Manage** link on the **BDN topology** mini-map
    opens the BDN network screen.

## Inspect and tune the BDN network

  1. **Choose a cluster**
On the **BDN network** screen, use the **mainnet / testnet** selector in the
    header to switch clusters. The star-topology map shows the **root** node at
    the center with all **edge** relays around it.
  2. **Select an edge to inspect**
Click a node in the topology map, or a row in the **Edge relays** table, to
    load the edge inspector on the right. The inspector shows the edge's
    **Region**, **Mode**, **RTT → root**, **Subscribers**, **Landed / s**,
    **TPU target**, and health status.
  3. **Manage a selected edge**
In the inspector, you can copy the edge's fan-out track. You can click
    **Re-subscribe**. You can use the power button to take the edge offline.
    Use **Re-sync edges** in the header to refresh the whole mesh. Use
    **Add edge** to register a new relay.
  4. **Set the node role**
In the **Node role** card, choose **root** or **edge** for this node. In
    **edge** mode, you set the upstream `root` (`quic://host:port`). A root
    ingests and fans out. An edge subscribes from the root. You can also set the
    default `leader` landing target and check the `cluster`.
  5. **Tune the dedup cache**
The **Dedup cache** card shows cache entries, capacity, hit rate, and
    occupancy. Deduplication keys on the transaction's first 64 bytes (the
    Solana signature). Drag the **dedup_ttl_secs** slider to set how long the
    cache keeps a signature. After that time, the BDN lets a resubmit through
    again.

> **TIP:**
> A single edge often causes land-rate problems. Sort the edge table by
> **Landed/s** or **RTT**. Examine an edge with high RTT or `offline` status
> first.

## Watch TPU landing and the leader schedule

  1. **Read the config strip**
The **TPU landing** screen opens with four mini-cards: `rpc_url` health,
    `slot_refresh_ms`, `fanout_leaders`, and the client cert status. These cards
    show whether leader discovery is live and how wide the fan-out currently
    reaches.
  2. **Follow the leader schedule**
The **Leader schedule** timeline shows the **current**, **next**, and
    **upcoming** leaders (four slots each). The console discovers them from the
    on-chain leader schedule. Highlighted cards show the leaders that your
    submissions currently fan out to. Each card shows the leader's land success
    percentage and latency.
  3. **Inspect one leader**
Click a leader card to load its detail. The detail shows **Land success**,
    **Failed lands**, **p50 latency**, and copy-ready **validator identity** and
    **TPU QUIC endpoint** values. The **Recently completed leaders** table shows
    land results from the last rotations.
  4. **Adjust landing config**
In the **Landing config** card, choose **auto-discover** (the console
    resolves leaders from the schedule) or **manual host** (enter a validator
    host and QUIC port). Drag **fanout_leaders** to set how many leaders each
    transaction targets. Set the `rpc_url`. Then click **Apply**. **Test land**
    sends a probe with the current configuration.

## Submit a transaction

  1. **Open the Submit console**
On the **Submit** screen, choose a **Route**: **/bdn/submit · fan-out**
    (lands across all edges) or **/tpu · direct** (current + next leader only).
  2. **Choose a leader target**
Set **Leader target** to **auto-discover** or **explicit host**. If you
    choose explicit, enter the validator **host** and **port** (or **quic_port**
    on the TPU route).
  3. **Paste the signed transaction**
Paste a base58 or base64 signed transaction into **Raw transaction**. The
    first 64 bytes are the Solana signature. The BDN uses them as the dedup key.
    The panel shows the exact `POST` endpoint that the console will call.
  4. **Submit and read the result**
Click **Submit**. The **Result** card shows the returned signature, the
    status (`ingested · landed`), and the route. The **Equivalent request** card
    shows a copy-ready `curl --http3` command for the same call.

> **WARNING:**
> A submit requires a valid signed transaction and an API key with the **bdn**
> or **tpu** scope. All traffic uses HTTP/3 over QUIC. There is no TCP fallback.
> The service refuses a client that cannot negotiate QUIC.

## Monitor and configure data feeds

  1. **Watch the track cards**
The **Data feeds** screen shows the **slots**, **blockhash**, and
    **priorityFee** tracks. Each card shows freshness, update rate, subscriber
    count, and whether the track is **push · WS** or **poll · HTTP**. Click a
    card to load its detail. The detail includes the last payload and a
    freshness sparkline.
  2. **Tune your feed cadence**
In the **Feed cadence** card, drag **tick_ms** (base poll interval),
    **blockhash_every**, and **fee_every** (publish every N ticks). Then click
    **Apply cadence**. Cadence is per-organization. The console saves it to your
    private feed configuration.
  3. **Bring your own Geyser feed**
In **Private Geyser feed**, set the BDN to your own Yellowstone-Geyser
    gRPC endpoint. Enter the `grpc_url` and `x-token`. Then click
    **Save endpoint**. The BDN publishes your feed to your own private track.
    Use **Remove** to clear the endpoint.

> **NOTE:**
> The console **seals** the `x-token` for a private Geyser feed **at rest** under
> your organization. The console never shows the token again. If the panel reports
> the token as `unreadable`, enter it again to reseal it. You must be signed in to
> configure a private feed.

## Build and land an MEV bundle

  1. **Assemble the bundle**
On the **MEV bundles** screen, paste up to **five** base64 signed
    transactions into **Signed transactions**, one per line. Order is important:
    the bundle lands atomically in the order that you give. The `txs` counter
    turns red above the limit of five.
  2. **Set the tip**
Choose **Tip routing**: **static** (drag the **tip_lamports** slider) or
    **auto (p95 fee)**. Copy the **Tip account** if you need it. The panel shows
    the tip amount in lamports and SOL.
  3. **Submit the bundle**
Click **Submit bundle**. When the BDN accepts the bundle, a `submitted` pill
    appears with the bundle id. The **Recent bundles** table shows each bundle's
    tx count, tip, state, landing leader, and slot.

## Trace transactions in the ledger

  1. **Filter and search**
On the **Transactions** screen, use the segmented filter (**All / Landed /
    Dropped / Dedup / TPU**) to narrow the ledger. Use the search box to search
    by signature or leader. The summary chips show the landed count, dedup hits,
    and land rate.
  2. **Open a transaction**
Click a row to open the detail drawer. The drawer shows the full signature,
    route, ingest node, landing leader, fan-out breadth, landed slot, bytes,
    latency, and dedup status. It also shows a **Pipeline** view of the
    ingest → dedup → fan-out → land stages.
  3. **Export or inspect on chain**
In the drawer, click **View on explorer** to open the transaction. Click
    **Copy as cURL** to copy a runnable `getTransaction` call. Use **Export** in
    the header to download the currently filtered rows as CSV. Use **Live tail**
    to refresh the ledger.

## Review analytics

  1. **Set the range**
On the **Analytics** screen, pick **1h / 24h / 7d**. The top row plots
    **Land rate** (BDN vs. TPU) and **Land latency** percentiles (p50 / p95 /
    p99).
  2. **Read fan-out and dedup**
The **Fan-out volume** bars show tx/s across edges. The **Dedup hit ratio**
    donut shows how many duplicate signatures the BDN suppressed, and how many
    transactions that saved.
  3. **Break down by leader and region**
The **By leader** table shows land success and p95 latency per validator.
    **Landed by region** shows each region's share. **Feed freshness SLO**
    compares actual latency against target latency per track. Click
    **Export CSV** to save the loaded series.

## See what's live on Multichain

  1. **Read the chain registry**
The **Multichain** screen shows every registered chain with its
    **short-id**, **namespace**, and status. Solana is **Live** today. Other
    chains show as **Not enabled** until they are enabled for your organization.
  2. **Understand the routing prefix**
The **Short-id namespace** card shows the compact 1-byte routing prefix that
    the BDN adds to every fanned-out transaction. It also shows how additional
    chains register a short-id and a namespace. **Per-chain capabilities** shows
    what each chain exposes and what is planned.

## Manage API keys and endpoints

  1. **Review the QUIC endpoints**
On the **API keys** screen, the **QUIC endpoints** table shows each
    surface, method, path, and QUIC authority. Clients discover the QUIC port
    through a DNS `HTTPS` record on `crypto.firstbyte.fast`. There is no TCP
    fallback.
  2. **Create an API key**
Click **Create key**. Enter a **Name**. Select the **scopes** that you need
    (**bdn**, **tpu**, **feeds**, **read**). Click **Create key** to create the
    key.
  3. **Copy the token once**
The console shows the full token **once**, immediately after creation. Copy
    the token and store it securely. You cannot retrieve it again. After that,
    the keys table shows only a masked preview, the scopes, and the last-used
    time.
  4. **Revoke or grab a snippet**
Use the trash icon in the keys table to **revoke** a key. The **SDK
    snippets** card shows copy-ready **Rust**, **TypeScript**, and **cURL**
    examples for raw-QUIC submit and MoQT feed subscribe.

> **WARNING:**
> The console shows the cleartext token only at creation. If you lose the token,
> revoke the key and create a new key. There is no way to show an existing key
> again.

## Track usage and observability

  1. **Read the meter strip**
The **Usage & billing** screen shows the current period's metered
    counts: **tx_sent**, **tx_bytes**, **fanout**, and **landed** (with failed
    count).
  2. **Check transport health**
The **Transport observability** panel shows live BDN metrics: land success,
    p50 / p95 land latency, block compression, short-id table size, blocks
    published, and get-txs hit / recovery rates. The **Lands · recent window**
    chart shows live land throughput.
  3. **Scan recent errors**
The **Recent errors** table shows land / submit failures across nodes with
    their timestamp and cluster. An empty list means that the land and submit
    paths are healthy.

> **NOTE:**
> This screen shows **observability data, not a bill**. FirstByte meters
> transport counts and latency, not a per-transaction price.

## Next steps

  - **[Crypto details](./details)** — Learn how the BDN, feeds, and TPU landing work end to end.
  - **[SDK methods](./sdk-methods)** — Submit transactions and subscribe to feeds from your own code.