Slashing
The content on this page is currently under review and subject to change.
How Slashing Works
Slashing is a penalty mechanism designed to ensure committers keep their promise of providing consistent compute power over time. If a committer fails to stay online or their measured compute in any of the four benchmark metrics falls below what they committed - for example, because phones went offline and were not replaced - their stake gets slashed in proportion to the shortfall. For instance, if a committer promised 100 GB of RAM but only delivers 80 GB, they will be slashed proportionally for that 20% shortfall in the RAM metric.
This mechanism incentivizes providers to actively maintain their deployed Acurast phones and farms, ensuring they're always running and replacing capacity with equally powerful devices when needed. Both the committer and their delegators share this risk, as slashing affects all staked tokens proportionally.
When Slashing Occurs
When a committer's Current Compute falls below their Committed Compute in any of the four benchmark metrics during an epoch, they become slashable for that epoch. Slashing must be triggered on-chain by a Slasher- anyone with an Acurast account who detects the violation. Slashing can be triggered earliest in the epoch after the epoch where the commitment was violated.
How Slashing Penalties Are Calculated
Once slashing is triggered, penalties are calculated independently for each Benchmark Metric where there's a shortfall. The slashing amount for each metric is determined by multiplying the stake amount by the maximum slash rate (0.003424657534% per epoch), the metric's weight, and the percentage shortfall.
For example, if a committer with a 1,000-token stake falls 50% short on RAM (which has a weight of 0.4615), they would be slashed 0.0079 tokens for that metric alone. If they have shortfalls across multiple metrics, each penalty is calculated separately and then summed together - though the total can never exceed 0.003424657534% of the stake per epoch.
Slashing Examples
Example 1: Complete Loss of Compute
A committer has a 1,000-token stake. In an observed epoch, their Current Compute falls 100% short in all four metrics (CPU Single, CPU Multi, RAM, and Storage). Since they failed to provide any of their committed compute, they face the maximum penalty of 0.003424657534% of their stake per epoch, resulting in a total slash of 0.0342 tokens for this epoch. This breaks down as: 0.0079 tokens for CPU Single Core, 0.0079 tokens for CPU Multi Core, 0.0158 tokens for RAM, and 0.0026 tokens for Storage.
Example 2 (fictional): Partial Loss of exactly 50% Across All Metrics
A committer has a 1,000-token stake. In an observed epoch, their compute falls 50% short across all four metrics. They are slashed proportionally for this epoch: 0.0040 tokens for CPU Single Core, 0.0040 tokens for CPU Multi Core, 0.0079 tokens for RAM, and 0.0013 tokens for Storage - totaling 0.0171 tokens (0.00171% of their stake per epoch).
Example 3 (realistic): Variable Shortfalls
A committer has a 1,000-token stake. In an observed epoch, their compute falls short by different amounts: 12% in CPU Single Core, 15% in CPU Multi Core, 10% in RAM, and 12% in Storage. The resulting penalties for this epoch are: 0.000948 tokens for CPU Single Core, 0.001185 tokens for CPU Multi Core, 0.001580 tokens for RAM, and 0.000316 tokens for Storage - totaling approximately 0.0040 tokens slashed for this epoch.
What Happens to Slashed Tokens
Of the slashed amount, 10% goes to the Slasher as a reward for detecting the violation, while the remaining 90% is immediately burned, reducing total supply and inflation.
Slashing Impact
Importantly, committers still earn rewards for any metrics where they met their commitment; only metrics with shortfalls result in slashing. This means partial performance is still rewarded, while failures are penalized proportionally.
Just as rewards flow from committers to their delegators, slashing penalties also affect delegators proportionally based on their stake. When a committer is slashed, each delegator loses the same percentage of their delegated stake as the committer loses from their own stake. However, delegators can redelegate to another committer at any time if they're concerned about their chosen committer's performance.