Slashable Offence

A slashable offence is the specific, checkable action that triggers a slash, the destruction or confiscation of part of a staked participant's bond as a penalty (see Slashing for the mechanism itself). Naming the mechanism isn't enough on its own; a staking system only works as designed if the list of offences that trigger it is precise, provable, and known in advance. Too broad a list, and honest participants get punished for bad luck (a server crash, a slow network) rather than bad behavior. Too narrow, and real cheating slips through unpunished. Most staked networks converge on the same rough taxonomy: intentional protocol violations that are unambiguous and provable (get slashed hard, immediately), and availability failures that might just be bad luck (get a smaller, cumulative penalty).

Where it comes from

The general "prove misbehavior, then slash" pattern was formalized for practical use by Vitalik Buterin and Virgil Griffith's 2017 Casper FFG paper, which defined validator equivocation (signing two conflicting blocks in the same round) as the canonical slashable offence for proof-of-stake blockchains. Applying the identical accountability logic to a different kind of staked network participant, not a block validator, but a GPU operator performing off-chain AI inference work, is not something the Casper FFG paper covers; it's Solidus's own extension of the pattern onto its compute network, built on top of its existing anti-cheat verification system rather than a separate invention.

Solidus status

Solidus runs two distinct slashing regimes today, at different levels of maturity. Validator slashing, for the chain's block-producing nodes, treats double-signing/equivocation and extended downtime as slashable, and is enforced in the shipped consensus engine (see Slashing for the full picture there).

Compute-operator slashing is newer and narrower. A dedicated ComputeSlash transaction type exists on-chain and is wired directly to the compute broker's anti-cheat logic: a canary mismatch (a node fails a synthetic, known-answer test job it couldn't distinguish from a real one) triggers it immediately; a spot-check mismatch only triggers it after an independent referee re-run confirms the discrepancy, guarding against a merely-flaky reference run producing a false slash. Both paths are real, running code, not a design document. What's not yet finalized is the penalty schedule itself: Solidus's own compute-network design documentation proposes specific stake percentages for each offence (a canary mismatch costing more than a mere no-show, for instance) but labels that table explicitly "proposed, founder-tunable". The mechanism that can slash is shipped; the exact price of each offence is still a draft awaiting a decision. And because no $SLDS token has ever been publicly distributed, every slash recorded today, for a validator or a compute operator, only adjusts a testnet-internal number with no real economic value behind it yet.

Proof: the ComputeSlash transaction handler, which sets a slashed operator's status to Slashed and its reputation to zero, is visible in source in the public solidusnetwork/protocol repository's solidus-txns crate. No live compute-slashing event has been publicly observed: the broker currently reports zero active operator nodes at broker.solidus.network/health, so there is nothing live on the network today to demonstrate a slash against.