A slash is an automatic protocol penalty when a manager's pool fails its on-chain commitments — usually missed heartbeats, missed reports, or a job that the assigned processor never completed.

It is enforced by the chain itself via the acurastCompute pallet, not by any human or governance vote. The Recent Slash Events feed is built from the resulting acurastCompute.Slashed events.

Each slash splits into two parts. Burned ACU is permanently removed from supply — it leaves the network. Reward ACU goes to the slot's reporter as a bounty for catching the failure.

On a typical slash about three quarters is burned and one quarter is paid out, but the exact ratio is set on-chain and can change. Add the two columns together to get the total slashed amount.

The chain sizes the slash from the offending pool's stake — bigger pools that miss commitments lose proportionally more ACU. It is not a flat fee.

The 'Largest single' KPI at the top of the page tracks the biggest individual event over the 30-day window so you can spot outliers without scrolling the feed.

Slashing is heavy-tailed in practice: most managers go a full 30 days with zero slashes, while a handful absorb the bulk of events because of a single bad week — devices going offline together, an app update breaking heartbeats, or a misconfigured pool.

The chart sorts by total slashed ACU rather than count so a single big event surfaces alongside chronic small ones.

Yes. Delegated stake is at risk alongside the manager's own stake — that is the whole point of delegation as a sybil-resistant signal. When the pool gets slashed, every delegator's share takes a proportional hit.

Your delegator APR on the /apr page already nets out historical slashing, so a manager that has been slashed regularly will show a lower realized return even if their headline operator APR looks healthy.

Slash events stop appearing in the feed, the timeline goes flat, and pool health on the manager's staking page climbs back. There is no explicit 'unslash' — already-burned ACU stays burned.

Use the daily timeline plus the manager-specific slash-risk view on /managers/<id>/delegation to confirm whether recent activity is a one-off incident or an ongoing problem.

Keep heartbeats consistent: stable connectivity, the latest Acurast app build, battery optimization disabled, and processors that aren't double-booked across managers.

Watch the /managers/<id>/fleet pages for processors stuck in 'watch' or 'down' state — those are the ones most likely to trigger the next slash. The Build column flags devices that have fallen behind the latest stable release.

Every event traces back to an acurastCompute.Slashed extrinsic finalized on-chain. The indexer records the block number, the commitment ID, the manager, and the burned/reward split exactly as the runtime emitted it.

Click any block number in the feed to inspect the original extrinsic. The 30-day numbers update within seconds of finalization — there is no separate aggregation lag.