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

​
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.
  • Authentication — API keys, relay tokens, and where the portal session fits
  • Telemetry — the operational streams behind the observability screens