# Crypto console metrics reference > How the crypto overview screen computes land rate, what the KPI strip and BDN edge counts mean, and why the submit endpoint reports not deployed. The crypto **Overview** screen is a read-only aggregate of five procedures plus one live deployment signal. Every number on that screen comes from one of the sources below, and nothing on the screen is computed from a client-side constant: | Source | What the screen renders from it | | ------------------------ | ---------------------------------------------------------------------- | | `overview.kpis` | The KPI strip across the top. | | `analytics.summary` | The **Land rate** chart (`landRate.bdn`, `landRate.tpu`). | | `overview.recent` | The **Recent landings** list. | | `bdn.root` | The root node of the **BDN topology** mini-map. | | `bdn.edges` | The edges on the mini-map, and the `N of M edges online` sub-heading. | | `useBdnDeployed()` | The `online` / `not deployed` pill on the **Submit endpoint** card. | The **Refresh** button refetches all five queries at once. The queries also refetch on their own intervals, so Refresh is an explicit operator pull rather than the only way to get fresh data. ## Land rate: how it is measured Land rate is the share of transactions you submitted that were successfully landed on the TPU, expressed as a percentage. The numerator is successful TPU landings; the denominator is submitted transactions. The chart is drawn with a fixed axis maximum of 100, so a series value is already a percentage — the console does not rescale it. The chart covers the last hour, ending at the moment of the last fetch. Its x-axis is labelled `−60m`, `−45m`, `−30m`, `−15m`, `now`. Those labels are axis ticks, not bucket boundaries: the number of points plotted is however many values `analytics.summary` returns in `landRate.bdn` and `landRate.tpu`, spread evenly across the hour. So the effective bucket width is one hour divided by the series length, and it changes if the procedure changes its resolution. If both series come back empty, the card shows the **No land-rate data yet** empty state instead of an all-zero chart. An empty series therefore means "no land-rate history exists", not "land rate is 0%" — the two are different conditions and the console deliberately does not draw the second as a flat line. ## BDN fan-out vs direct TPU The chart always plots two series against the same axis, with a legend in the card header: | Series | Legend colour | Field | | --------------- | -------------- | ------------------- | | BDN fan-out | `--chart-1` | `landRate.bdn` | | Direct TPU | `--chart-2` | `landRate.tpu` | **BDN fan-out** is the land rate for transactions that FirstByte relayed through the Blockchain Distribution Network — the path you get from `/bdn/submit`. **Direct TPU** is the land rate for transactions sent straight at the TPU. Both series are measured the same way (landings over submissions), so they are directly comparable: the gap between the two lines is the difference the fan-out path made over the same window. Either series can be empty independently. The card renders the chart as long as *at least one* of the two arrays is non-empty, so a single-line chart is a normal state — it means only one submission path carried traffic in the window. ## The overview KPI strip The strip renders whatever `overview.kpis` returns, in the order returned. Each item carries a `key` (used as the React key) and the display props for the `Kpi` tile; the screen does not add, reorder, filter or derive tiles. To change what appears in the strip, change the procedure — there is no client-side list. The strip is laid out as an auto-fitting grid of columns with a minimum width, not as a fixed column count. A fixed seven-column layout truncated tile labels at ordinary content widths, so tiles now wrap onto a second row instead of clipping their labels. Because the layout is not pinned to a count, the procedure can return a different number of tiles without breaking the screen. ## Live windows and the missing range control The overview procedures serve fixed live windows. There is no range selector on this screen: an earlier range control existed but changed nothing, because none of the overview procedures accept a range argument. If you need a different window, use the ledger and analytics screens rather than expecting the overview to re-scope. ## Edge status and the online count The topology card's sub-heading reads `N of M edges online`, where: - `M` is `edges.length` — every edge `bdn.edges` returned. - `N` is the count of edges whose `status` is **not** `offline`. The overview makes only that one distinction. `offline` is the single status the screen tests for by name; every other status value an edge can carry counts toward the online tally. That means an edge in a transitional or degraded state is counted as online here. The overview is a rollup, not a diagnosis — use **Manage** (the button in the card header, and clicking any node on the map) to open the BDN network screen and see the specific per-edge status. The mini-map itself is drawn by `BdnMap` from `bdn.root` plus `bdn.edges`, in compact mode. Selecting anything on it navigates to the BDN network screen; the map on the overview has no other interaction. ## When the submit endpoint reports not deployed The pill on the **Submit endpoint** card has exactly two states, driven by the `useBdnDeployed()` hook: | Pill | Meaning | | -------------- | ----------------------------------------------------------- | | `online` | The BDN data plane is deployed and live. | | `not deployed` | The BDN data plane is not live. | `useBdnDeployed()` is the same live signal that feeds the health pip in the top bar and the BDN network screen, so all three always agree. This card previously read a hardcoded build-time flag, which let it claim `online` while the rest of the app showed the real state; that flag is gone. `not deployed` is a statement about the data plane, not about your credentials or the ingress host. It is the same condition that produces the two empty states on this screen — **No land-rate data yet** and **No landings yet** both explain that data appears once the BDN data plane is live. If you see `not deployed` together with those two empty states, that is one fact reported three times, not three separate problems. ## The submit quickstart snippet The card lists the surfaces the submit endpoint exposes as tags: `/bdn/submit`, `/tpu`, `ALPN solana-tpu`, and `0-RTT`. Below them is a copyable fan-out submit command: ```bash curl --http3 https://crypto./bdn/submit?leader=auto \ -H "Authorization: Bearer $CLUTCHCALL_API_KEY" \ -H "Content-Type: application/octet-stream" \ --data-binary @tx.bin ``` Two details of the snippet are generated rather than fixed: - **The host** follows the origin the console is served from. A console hostname ending in `firstbyte.fast` produces `crypto.firstbyte.fast`; anything else falls back to `crypto.clutchcall.dev`. This is the documented BDN submit origin — see the [crypto cookbook](/modalities/crypto/cookbook). - **`?leader=auto`** is what makes this the *fan-out* submit shown in the card's eyebrow, as opposed to addressing a leader yourself. The body is the raw transaction as `application/octet-stream`, and the request authenticates with a control-plane API key bearer token — see [Authentication](/concepts/authentication). ## Recent landings `overview.recent` returns landed transactions only; every row in the list is rendered with a `landed` pill. Each row carries: | Field | Shown as | | --------- | --------------------------------------------------------------- | | `sig` | The base58 transaction signature, truncated head-and-tail. | | `node` | The BDN node that landed it. | | `cluster` | The cluster that node belongs to. | The first two rows are marked live. That is a presentation cue for the top of a streaming list, not a property of those transactions. The full, untruncated history lives behind **View ledger**; the overview list is a preview. ## Related - [Telephony Metrics](/glossary/metrics) — metric definitions and formulas - [Telemetry](/platform/telemetry) — metrics, traces and CDR streams - [Authentication](/concepts/authentication) — API keys for the submit endpoint