THORChain Slash Monitor

Running or delegating to a THORChain node means living with slash points. They accrue quietly in the background, they reset every churn, and by the time you notice them they have already shaved RUNE off your bond rewards. Until now there was no simple way to see, per node and per churn, what was slashed, why, and what it cost.

That’s what the RUNEBond Slash Monitor does. This guide explains exactly what the dashboard shows, how it interprets “loss,” the methodology behind the numbers.

What are slash points on THORChain?

THORChain assigns slash points to active validators that fail their duties for example:

• failing to observe an inbound transaction the rest of the network observed,
• failing to participate in a keysign (TSS signing) ceremony,
• missing block signatures,
• and other liveness/availability faults.

Slash points are an accounting penalty, not a direct confiscation. At each churn (the periodic rotation of the validator set), THORChain pays out accumulated bond rewards weighted by each node’s effective bond and reduced by its slash points. More slash points → a smaller slice of the reward pool. Slash points are scoped to the churn window, so they effectively reset each period.

Key idea: A slash point doesn’t take RUNE out of your bond. It takes RUNE out of the reward you would have earned. The Slash Monitor is built to make that opportunity cost visible and concrete.

What the dashboard shows

The Slash Monitor lives as a tab on every node’s detail page. Open any node on RUNEBond, switch to the Slash Monitor tab, and you get that node’s full slash picture. Everything is organized around a churn-period selector with an Open / Closed status pill because slash points only make sense within a churn.

The headline: four cards

For the selected churn the tab leads with four KPI cards:

Card	What it means
Slash points · this churn	The node’s slash-point counter for the churn reproduced exactly as THORChain keeps it (charges net against refunds, floored at zero). This is the number that actually drove the reward penalty.
Lost rewards (est.)	The bond reward, in RUNE, the node forfeited to those slash points this churn plus the percentage of its potential reward that represents.
Net reward (est.)	The RUNE the node earned this churn.
Vs network average	How this node compares to the rest of the active set: a ratio like “2.3× worse” (or better), the network-average slash points, and “worse than X of Y nodes.” Shown only when the node has slash points and there’s a set to compare against.

Below the cards

• Network-observation trend a per-chain line chart of the observation faults that build up over the churn rather than mapping to a single transaction (network fee, solvency, errata, TSS/key setup). Each chain is a line of cumulative net penalty. Pick a time range (1H / 6H / 1D / All).
• Slash points by reason & by chain horizontal bars ranking which fault types and which chains drove the penalty, worst-first.
• Recent slashes a paginated table of the individual penalty events anchored to a specific transaction or signature (height, reason, chain, txid), newest first. You can filter by reason and search by tx hash (observed or THORChain). The observation faults that only build up over time are deliberately kept out of this table they live in the trend chart above.

How “effective” slashes are calculated (refund noise removed)

THORChain slashes optimistically. The moment a node has a pending obligation, the protocol charges a slash point (a + movement). Once the node contributes to consensus, that point is refunded (a − movement) typically in a later block. The raw event stream is therefore full of paired +N/−N movements for the same incident that net to zero (they’re actually a signal of good behavior, not a penalty)

The Slash Monitor collapses each incident matching a charge with its refund by the obligation they share (the observed transaction, the keysign, the block) and:

• keeps only incidents whose signed points net positive (an effective slash: points were charged and not fully refunded), and
• nets the totals with sign, so that a later refund in a subsequent block reduces the penalty.

How charge and refund get paired depends on the fault type:

• Direct penalties (failed keygen, double block sign, missed block signature) are never refunded each counts as-is, per block.
• Failed keysign splits in two: the +2 “culprit” penalty is a concrete per-block incident, while the ±1 “did-you-participate” movements net out over the churn.
• Observation faults tied to a transaction (failed observe txin/txout) net per observed transaction, across blocks.
• Observation faults without one (network fee, solvency, errata, TSS pool) net per chain over the whole churn.

Because refunds can arrive late, a positive observation net only becomes firm once its latest movement is at least 10 blocks (~1 min) old. THORChain’s own observation grace window so a not-yet-arrived refund is never mistaken for a real penalty. Direct penalties have no refund and show instantly.

The result is net slash points: the economic penalty the node was genuinely left with, not the raw, inflated count of optimistic deductions. Every figure on the dashboard, the headline counter, the by-reason and by-chain breakdowns, the trend chart, and the network comparison is computed this way, so they always reconcile.

What the dashboard does not cover: principal-bond slashing

This is the most important scope note, and we want it to be crystal clear at launch.

THORChain has two distinct penalty mechanisms, and the Slash Monitor measures only the first:

1. Slash points → reduced bond rewards. A liveness/availability penalty that lowers the rewards a node earns at churn. This is what the Slash Monitor tracks.
2. Direct slashing of the principal bond. For certain severe events, where a node causes an actual, quantifiable loss to the network (for example, failing to sign an outbound so the network has to cover it, or other fund-loss faults) THORChain deducts RUNE directly from the node’s bonded principal (historically at a multiple of the value lost). This reduces the bonded capital itself, not just the reward. The Slash Monitor does not measure this.

In other words:

The “Lost rewards (RUNE)” figure is the reward you forfeited to slash points. It is not the amount of bond that was confiscated. A node can suffer a principal-bond slash that this dashboard will not show.

Who should use it, and how

• Node operators: Spot recurring fault reasons before they compound across churns, quantify exactly how much RUNE your slash points cost you, and compare what you earned vs. what you lost to prioritize fixes (a chain client that keeps failing to observe, a flaky keysign setup, etc.).
• Delegators / bond providers: Before bonding, check a node’s recent slash history and reward efficiency. A node with a clean, low net-slash record across recent churns is keeping more of your rewards just remember to separately assess principal-bond risk.
• Researchers and the community: A transparent, reconcilable view of network-wide liveness and the real RUNE cost of slashing.

---

Bottom line

The RUNEBond Slash Monitor turns a noisy, optimistic, sign-flipped event stream into two clear answers per node, per churn: how many slash points actually stuck, and how much RUNE in bond rewards that cost. It does this with the chain’s own math, refund noise removed.

Just remember the scope: it measures reward loss from slash points, the deterministic, every-churn penalty not the rarer, direct slashing of principal bond. Use it for liveness and reward-efficiency insight, and assess principal-bond risk separately.