← Network

01What this page is#

Every number on the dashboard is explained here, once, in plain language — including what it cannot tell you.

The dashboard is a public view of the Crosslink network's health, built from one node's read-only RPCs. It exists so delegators can choose a finalizer on evidence, and so operators can see what their participation is worth. Every finalizer is measured by the same published rules — including the one run by whoever hosts this instance. Where a claim depends on how the protocol works, it has been checked against the node's source code, and this page says where (§15).

02Finality and the ⅓ line#

A block is final when two thirds of all bonded stake signs it. So anyone holding more than one third can stop finality — not slow it, stop it.

The exact rule in the consensus engine: yes-precommit stake must reach 2f+1, where f = ⌊(S−1)/3⌋ and S is total voting power — a hair under 66.67% of stake. Withhold more than a third and that threshold is arithmetically unreachable. It does not matter whether the third is one operator or twenty acting together. The Nakamoto coefficient on the front page is the size of the smallest group that could do it; at 1, a single operator's outage stops finality for everyone.

Three related things are measured separately, because merging them would hide the interesting one:

• Signed stake per decision — how far above the two-thirds bar each decision cleared. A margin trending toward zero is the only advance warning there is.
• Heights needing a retry — the round a height finally committed at. Round R means rounds 0…R−1 failed to gather a quorum first.
• Stalls — no decision for several times the normal cadence.

Two honest caveats. Extra rounds are not automatically a fault: when finality has caught up to the tip there is nothing to propose, and a round times out with nobody to blame. And during a genuine network-wide stall no votes are observed at all, so nothing is counted against anyone and scores drift upward — read the stall figures alongside the grades, never instead of them.

03The grade: two signals#

The grade answers one question: when the network finalized blocks, was this finalizer doing the finalizing? Two independent measurements answer it, and the stronger one counts for more.

• Certificates — chain-verified, weight 0.6. Every finalized decision carries its commit certificate: the set of signatures that finalized it. A finalizer either signed the decision or it did not — our connectivity cannot distort this. It is the closest thing to ground truth available.
• Votes seen — this node's view, weight 0.4. Votes are visible for only ~1–2 seconds at the end of each BFT height, and only when they reach this node. This notices engagement earlier than certificates do, but a finalizer poorly connected to us under-measures here — which is exactly why it counts for less.

If only one signal has evidence for a finalizer, the grade uses that signal alone: a finalizer whose votes never reach us but which demonstrably signs certificates is graded on the certificates, not punished for our blind spot. The grade is not a yield estimate, and it says nothing about commission, custody, or infrastructure beyond finalizing blocks.

04The formula, in plain terms#

Each signal is a hit rate, gently pulled toward the network average until there is enough evidence to trust it on its own. Then the two are blended, 60/40.

signal = (hits + α·μ) / (observed + α)
score  = 0.6·certificates + 0.4·votes     (renormalised if one signal is absent)

• hits — certificates signed, or heights where the vote reached us
• observed — decisions observed, or heights where the vote window was captured at all
• μ — that signal's average across finalizers seen at least once
• α — how much evidence it takes to move off the average: 6 observations

Why the pull toward the average: a finalizer seen in five of five heights has not proven it is perfect. The score treats it as "probably about average, early signs good" until real evidence accumulates. Grades: A+ ≥ 97 · A ≥ 93 · A− ≥ 90 · B+ ≥ 87 · B ≥ 83 · B− ≥ 80 · C+ ≥ 75 · C ≥ 70 · D ≥ 60 · F below.

05Sample sizes#

A grade without its sample size is an opinion. Every grade here ships with its evidence counts, everywhere it appears.

The table header says how many decisions the window covers — a rolling seven days of them (configurable), so a grade reflects a week of behaviour rather than the last couple of hours. The little strips beside the numbers are deliberately shorter: they show only the most recent ten heights, as a recency diagnostic against the week-long rates. The finalizing column shows both rates; the tooltip on any grade and the popover on any row spell out certificates signed / decisions observed and heights voted / heights captured. Below 5 observations a signal gives no evidence at all; below 30 the grade is marked provisional (an asterisk) — early scores sit below where they settle, so a provisional C is a statement about the sample, not the operator.

06Finalizers shown as "not observed"#

Some finalizers appear in neither signal. They get no grade — deliberately not an F. Silence is not evidence of failure.

An F is a verdict about an operator, and this data cannot support one. A finalizer can be absent from our view because it is genuinely offline, because its key is registered in a form the voting path never matches (a real bug on this network that hits blameless operators), or because this node simply does not receive its messages. Those three look identical from one vantage point — and only the first is the operator's fault. Such finalizers are also excluded from the network average, so they cannot drag down the grades of operators we can see.

What it means for a delegator: this page cannot confirm that stake delegated there takes part in finality — and per §08, prolonged darkness carries real tail risk. Ask the operator; do not assume either way.

07Proposer slots — measured, not yet graded#

The protocol chooses who proposes each round, deterministically, by stake. We reproduce that choice exactly — so when a round fails, we know whose slot it was.

The selection is a fixed keyed hash of (height, round) over the roster's cumulative stake. Our reproduction is validated vector-for-vector against the node's own code. A height that committed at round r attributes a missed slot to the proposers of rounds 0…r−1 and a delivered slot to round r's proposer. Shown as slots delivered / slots given wherever it has data.

It is not yet part of the grade: attribution only covers heights observed live — the roster used is the one fetched at observation time, never a reconstruction — so the sample grows from the day this shipped. When it is meaningful it will join the score, and this page will change first. One early network finding it already supports: finalizers that never vote also fail every proposer slot they are drawn for, so each one imposes a retry-round tax on the whole network whenever selected.

08Slashing, really#

Slashing here is declared, not automatic — and when it happens, delegators' bonds burn with the finalizer. It has happened once.

There is no protocol rule that docks a finalizer for a missed vote. Instead, a hardfork can name terminated finalizers: at the fork's activation height the identity is removed from the network and every bond delegated to it is burned — the operator's and the delegators' alike. This is verified in the node source (§15), and it has happened once: one finalizer, terminated at block 225,000, shipped in the node's built-in rules.

The delegator consequence is the point of this whole page: persistent non-response is the behaviour that gets an identity terminated, and termination takes its delegators down with it. Delegating to a finalizer nobody can see finalizing is not just forgone influence — it is tail risk. Terminated identities are labelled on their finalizer pages and are absent from the roster by construction.

09Bonds and the delegation window#

A bond is your stake, locked to a finalizer of your choice. It stays yours, it earns automatically, and you can unbond it — with the one exception in §08.

Bonds land in the first portion of every staking cycle (the front page shows the live window and countdown; on the current network that is the first 70 of every 150 blocks). A bond outside the window simply waits for the next one. Rewards compound into the bond itself — there is nothing to claim. Your rewards follow your stake, not your finalizer's rank or size: two equally-reliable finalizers pay the same on the same stake, whether they rank first or thirtieth.

To bond, concretely: in the official Crosslink wallet, create a new delegation bond, paste the finalizer's key exactly as shown on its page here, and pick the amount — in practice bonds are placed in round amounts (10, 100, 1,000). The wallet returns a unique bond key that exists nowhere else — save it immediately; it is how you later prove and withdraw the bond. Then confirm the bond registered before considering it done. Feature-net wallets are still rough (upstream issues exist for staking flows), so verify rather than assume.

There is no commission on this network. The protocol splits each block's reward across all active bonds pro-rata and compounds it in place — no operator cut exists in the reward path, so a finalizer's fee schedule is not a thing you need to compare. Verified in the node source (§15).

10The staking rate#

The rate shown is measured from the chain, not promised — and it falls over time by design.

Crosslink pays a fixed reward per block, split across all bonded stake in proportion and compounded into the bonds. Because every bond grows by the same percentage, the median growth across finalizers isolates the protocol reward from new deposits — a mean would count other people's deposits as your yield. The annualised figure is "what the last day paid": the per-block reward is fixed while total stake grows, so the rate falls mechanically as more stake bonds.

There is deliberately no "percent of supply staked" figure: bonding burns value out of the monitored pools without crediting a published one, so no honest denominator exists. The metric is omitted rather than invented.

11How to choose a finalizer#

Pick a reliable finalizer outside the top group. It pays you exactly the same, and it makes the network harder to stop.

Working through the page, in order:

• Start outside the ⅓ group. The scoreboard draws the stall line; everything above it can stop finality together. The front page's suggestion box picks only from below it, at random, and nobody pays for placement.
• Check the finalizing rate, then its sample. A high certificate rate over hundreds of decisions is strong evidence. The same rate over eight is a provisional hint (§05).
• Treat "not observed" as a question, not an answer. It may be our blind spot — but slashing risk is real (§08), so ask the operator before bonding there.
• Ignore rank for rewards. Rewards follow your stake (§09). Size buys a finalizer influence, not you yield.
• Mind the window. Bond inside the open window; outside it your bond waits for the next cycle (§09).
• Come back occasionally. Grades move with evidence, the top group changes, and your bond can move too — spreading stake is reversible, staying concentrated is a standing risk.

12Privacy: why no bonds are listed#

The chain shows a wallet its own bonds and nobody else's. This page keeps it that way.

Publishing the positions of the node that happens to host this page would expose one delegator's holdings while every other delegator stayed private — a bad trade on a chain whose users chose it for privacy. Only per-finalizer totals, which the roster already makes public, are shown. The activity figures are parsed from public blocks and deliberately store no transaction ids and no bond keys, so nothing here can be linked back to a wallet.

13Identities#

Finalizers are 32-byte keys. Names are claimed, verified by signature, and buy no advantage.

Names, websites and links come from a registry file shipped with this app. Operators can add themselves by opening a pull request, or by signing a message with their finalizer key and sending it to whoever runs the instance — the signature proves the key is theirs. Every key, named or not, carries a deterministic glyph derived from its bytes so rows stay tellable-apart.

14Limitations you should know about#

This is one honest node's view — not the network's own ledger of itself.

• Votes count only if they reach us. A healthy finalizer poorly connected to this node under-measures on the votes signal — the reason certificates outweigh it (§03).
• The vote window is ~1–2 seconds per height. Heights missed entirely are excluded, never counted against anyone.
• Evidence grows forward only. The node offers no way to read historical certificates, so all windows begin when observation began — "since we started watching" is a permanent qualifier.
• One node cannot tell "the network stalled" from "we stalled". Periods when the collector was down are excluded from stall figures rather than counted, and the coverage check on the front page says how complete the window was.

15Where the data comes from#

Read-only RPCs on one node, checked against the node's source. Nothing here writes, stakes, or touches a wallet.

Chain and consensus facts are verified against the running build's source (Crosslink v13): the two-thirds rule and stake-weighted counting (tenderlink/src/lib.rs — ConsensusCounts, f_from_n, 2f+1), the commit certificate in the finality pointer (FatPointerSignature, bft.rs), proposer selection (proposer_from_height_round; port validated vector-for-vector ), slashing (terminated_finalizers in the hardfork rules; bonds set to Burned at activation), and the commission-free reward split (update_bonds_with_pos_issuance — pro-rata across active bonds, remainder to the largest). The full methodology, with file and line citations, is published in the repository as docs/SCORING.md.