Skip to main content
Specific TOKEN amounts, slash percentages, and fee splits on this page are not finalized. Tokenomics is under active review — see tokenomics for status. Treat numbers here as illustrative of the leading candidate model, not committed.

​
The four slashable offenses

OffenseHow it’s detectedCounter windowSlash schedule (1st/2nd/3rd in 90d)
Corrupted deliveryBLAKE3 mismatch on bytes you sent24 h5% / 10% / 20%
Phantom announcementYou said has_blob=true, stream failedNone (immediate)5% / 10% / 20%
Rate manipulationCharged rate ≠ advertised rate24 h5% / 10% / 20%
Blacklist violationServed blacklisted hash after compliance windowNone (immediate)10% / 25% / 50%
See slashing for the full mechanism. This page focuses on the operator’s response.

​
How challenges arrive

Anyone can file a challenge with a 50 TOKEN challenge bond. You (the accused) learn about it through:
  • On-chain event — SlashJudge emits a ChallengeFiled(nodeId, offenseType, ...) event.
  • Your own monitoring — if you monitor SlashJudge events, you see it in near-real-time.
A healthy operational posture includes a watcher that pages you on any ChallengeFiled event against your NodeId.

​
Immediate offenses (phantom, blacklist)

Phantom announcement and blacklist violation have no counter-evidence window. A successfully-filed challenge is decisive — SlashJudge resolves immediately and StakingRegistry.slash() is called. Your defensive posture is preventive, not reactive:
  • Phantom: keep probe_hold_duration at the default, monitor probe-hold saturation, never manually shrink the hold.
  • Blacklist: keep blacklist sync lag under 5 minutes; alert on any lag growth.
If a challenge of either type is filed, double-check it’s valid. If the challenge is invalid (the evidence is forged or stale beyond MAX_EVIDENCE_AGE_US), the challenger’s bond was filed against bad evidence — SlashJudge checks staleness and signature validity before acting. If the evidence is valid, you will be slashed.

​
Deferred offenses (corruption, rate manipulation)

These have a 24 h counter-evidence window. You can submit counter-evidence to refute the challenge.

​
Corruption counter-evidence

The challenger claims: “You delivered bytes that didn’t match the hash.” Your counter-evidence: a signed DeliveryReceipt from the original requester confirming what you actually delivered. The contract verifies: 
receipt.requester == challenge.challenger   // same party
receipt.hash      == challenge.hash         // same blob
receipt.content_match == true               // requester acknowledges clean delivery
If the receipt is valid and the requester is the challenger, you win. The challenger’s bond is slashed to your benefit. Practical point: you can only win if the challenger is genuinely the requester you delivered to. If a third party is challenging based on a forged claim, they’ll need forged evidence that fails signature verification — and the challenge will fail on its own without needing counter-evidence from you.

​
Rate-manipulation counter-evidence

The challenger claims: “You advertised rate X but charged Y.” Your counter-evidence: a signed RateChange gossip message showing a legitimate rate change happened between the disputed timestamps. Production RateChange messages carry a slash_sig specifically to serve this function. If you have the RateChange with a valid slash_sig and it fits within the disputed window, you win.

​
Filing a counter-challenge

SlashJudge.submitCounterEvidence(challengeId, evidence)
Must be within 24 h of the original challenge. Evidence format depends on offense type — see the contract interface for exact tuples.

​
Resolving challenges

After the 24 h window (or immediately for immediate offenses): 
SlashJudge.resolveChallenge(challengeId)
Anyone can call this. It:
  • Checks the counter-evidence (if any) against the challenge.
  • If the challenge wins: calls StakingRegistry.slash(nodeAddress, amount). 50% of the slashed TOKEN goes to the challenger; 50% is sent directly to the burn address.
  • If the challenge loses: challenger’s bond is slashed.

​
Challenging others

You can submit challenges against nodes you catch misbehaving. 50% bounty on successful slashes is real incentive. Operational requirements:
  • Capture evidence at the time of the offense. Store the signed ProbeResponse, StreamResponse, or RateChange with the misbehaving node’s slash_sig.
  • Submit within MAX_EVIDENCE_AGE_US. Stale evidence is rejected (the window is strictly less than the unbonding period).
  • Have your 50 TOKEN challenge bond available. Returned if the challenge succeeds.
Don’t file speculative challenges — the griefing deterrent works in both directions.

​
Recovering from a slash

A slash is not a ban. After being slashed:
  • Stake is reduced; the node continues running if above minStake.
  • Reputation takes a hit (gossip-propagated).
  • No deregistration is forced.
You can top up stake back to any level above minStake: 
TOKEN.approve(StakingRegistry, topUpAmount)
StakingRegistry.topUpStake(nodeId, topUpAmount)
Reputation recovery is slow — earn clean deliveries, avoid further offenses, wait for decay-to-neutral plus accumulated positive interactions. There’s no fast path.

​
If you’re slashed below minStake

The node is auto-ejected from the mesh. You can re-register with a fresh stake. Re-registration:
  • Increments your NodeInfo.nonce.
  • Preserves firstRegisteredAt — reputation cold-start bonuses do not apply to the same operator address twice.

​
Common mistakes

  • Ignoring decdn_slash_evidence_exposure_total. This is your “I’m about to be slashed” warning. Treat it as P1.
  • Downscaling probe_hold_duration to squeeze cache. You will phantom-announce the first time cache pressure spikes.
  • Rate changes during active streams without closing cleanly. Counts as rate manipulation.
  • Blacklist sync lag past 30 minutes. Emergency entries have a 2 h slash grace — 30 min of lag leaves 90 min of safety margin, which disappears fast under operational issues.