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

​
Recent landings

overview.recent returns landed transactions only; every row in the list is rendered with a landed pill. Each row carries: 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.