# Crypto console status and org scoping

> How the crypto console shell works: the BDN status pip, the fixed mainnet cluster pill, which screens need an active organisation, and what the sidebar runtime note means.

Every screen in the crypto console renders inside a shared shell: a
sidebar of grouped routes, a top bar with the organisation switcher, a
BDN status pip, a cluster pill, a docs link, a theme toggle, and the
account menu. The shell is the same on every route, so the same three
indicators follow you around. This page explains what each one reads
from and which screens change behaviour when no organisation is active.

## What the BDN status pip reads from

The top bar renders a coloured pip and a label immediately to the right
of the organisation switcher:

| Pip state  | Label               |
| ---------- | ------------------- |
| `healthy`  | `BDN live`          |
| `degraded` | `BDN not deployed`  |

The pip is driven by the shell's `useBdnDeployed()` hook. It answers one
question only: **is there a real BDN node deployment behind this
console?** It is not a per-organisation health check and it is not a
latency or throughput signal. Switching organisations in the tenant
switcher does not change the pip, because BDN deployment is a property
of the deployment you are pointed at, not of the org you are looking at.

Read it as a wiring indicator:

- **`BDN live`** — a BDN runtime is attached. Network, TPU landing,
  submission, feed and observability screens have a real backend to talk
  to.
- **`BDN not deployed`** — no BDN runtime is attached. The console shell,
  navigation, docs links and the guided tour all still work; the screens
  that depend on BDN runtime data have nothing to show.

`BDN not deployed` is the expected reading on a console that has been
provisioned but whose BDN nodes have not been stood up yet. It is not an
error state you need to clear before exploring the console.

## Why the cluster pill always says mainnet

Next to the pip is a secondary pill reading `mainnet`. It never changes,
and neither does the environment sub-label under each entry in the
organisation switcher.

The crypto vertical rides Solana mainnet. The shell therefore treats the
cluster as a constant per organisation rather than as a selectable
environment: every org in the switcher is stamped `mainnet`. There is no
devnet or testnet toggle in this console, and no per-environment split of
credentials, feeds or submission endpoints to reason about. If you are
looking for a staging surface, the organisation itself is the unit of
separation — create a separate org rather than switching cluster.

## Which screens are organisation-scoped

The active organisation comes from the shared org store, which the
organisation switcher writes to. The shell passes the active org down to
each routed screen as a `tenant` prop. When no organisation is active,
that prop is `null`, and the affected screens have no org to scope their
queries to.

| Route         | Nav label        | Receives the active org |
| ------------- | ---------------- | ----------------------- |
| `/`           | Overview         | Yes                     |
| `/get-started`| Get started      | No                      |
| `/bdn`        | BDN network      | Yes                     |
| `/tpu`        | TPU landing      | Yes                     |
| `/submit`     | Submit           | Yes                     |
| `/feeds`      | Feeds            | Yes                     |
| `/mev`        | MEV bundles      | Yes                     |
| `/txns`       | Transactions     | Yes                     |
| `/analytics`  | Analytics        | Yes                     |
| `/multichain` | Multichain       | Yes                     |
| `/developers` | API keys         | Yes                     |
| `/webhooks`   | Webhooks         | No                      |
| `/usage`      | Usage & billing  | Yes                     |

Two routes are deliberately outside org scope. **Get started** is the
onboarding surface and renders the same content regardless of org.
**Webhooks** is mounted without the org prop and manages its own scope.

Any unrecognised path redirects to `/` (Overview), so a stale bookmark
lands on the dashboard rather than a blank screen.

### When no organisation is active

If the shared org store has no active org, the shell degrades visibly
rather than silently:

- The organisation switcher button reads **`No org`** with the sub-label
  **`sign in on the portal`** instead of an org name and `mainnet`.
- The account menu's second line reads **`No org connected`**.
- Every org-scoped screen in the table above receives `tenant: null`.

The fix is always the same: sign in on the portal and pick an
organisation. The console does not create organisations itself.

## What "No BDN runtime samples" means

The sidebar footer carries two monospaced lines: `Crypto portal`, and
below it `No BDN runtime samples`.

The second line is a data-provenance note. This console ships **no
seeded, demo or sample BDN runtime data**. Anything you see on the BDN
network, TPU landing, submission, feed, MEV, transaction or analytics
screens came from an attached runtime. If the pip reads `BDN not
deployed`, empty tables and blank charts on those screens are the
correct, honest rendering — not a loading failure and not a bug in the
screen.

Pair the two indicators when you are triaging an empty screen:

| Pip                | Sidebar note              | Read as                                                    |
| ------------------ | ------------------------- | ---------------------------------------------------------- |
| `BDN live`         | `No BDN runtime samples`  | A runtime is attached; empty means genuinely no activity.   |
| `BDN not deployed` | `No BDN runtime samples`  | Nothing is attached; there is no data to show yet.          |

## Signing in and the account menu

A cold visitor is sent to the portal to sign in before the console
paints, so you should not normally reach a routed screen unauthenticated.

The avatar button at the right of the top bar opens the account menu,
which shows:

- the signed-in email address, or `Not signed in`;
- the active organisation as `Org · <name>`, or `No org connected`;
- **Portal hub** when signed in, or **Sign in on the portal** when not —
  both links leave the console for the portal;
- **Sign out**, which clears the session and redirects to the portal
  regardless of whether the sign-out call succeeded.

The email and org lines update live: the shell subscribes to auth state
changes, so signing out in another tab is reflected here without a
reload.

## Branding in the console shell

The sidebar lockup is white-label aware. White-labelled deployments
configure a mark and a wordmark in the portal under **Settings →
Branding**, and the shell renders those. Deployments without branding
configured render the built-in FirstByte lockup.

The small monospaced sub-label under the wordmark — `blockchain
distribution net` — is fixed and does not change with branding. It
describes what this surface is, not who ships it, so operators moving
between sibling portals can identify the crypto console at a glance.

## Shell controls that are not status

Three top-bar controls affect presentation only and carry no
organisation or runtime state:

- **Docs** — deep-links into this documentation set from the current
  screen's help entry.
- **Theme toggle** — flips the console between dark and light mode via
  the shell's tweaks store, which also persists other display tweaks.
- **Guided tour** — mounted over the routed screen; it walks the sidebar
  entries by route key.

An assist dock is mounted alongside the router and is available on every
route.

## Data freshness in the shell

The console's query client is configured with a short stale time of five
seconds and a single retry per query. In practice that means screens
refetch readily as you navigate between routes, and a transient failure
is retried once before the screen reports it. It also means the BDN pip
reflects deployment state within seconds of it changing, without a page
reload.

## Related

- [Authentication](/concepts/authentication) — API keys, relay tokens, and
  where the portal session fits
- [Telemetry](/platform/telemetry) — the operational streams behind the
  observability screens