A worked example of a slashing event on Mainnet, with the concrete vote, execute, and cleanup commands operators run end to end.

This page walks through a hypothetical slashing event on Mainnet so you can see how the pieces fit together. It assumes you have already read [Slashing](/docs/operator-guide/storage-nodes/slashing) for the conceptual model and the object IDs. The commands below are the ones operators actually run, with the live Mainnet object IDs filled in.

The scenario:

- The candidate is a misbehaving storage node with `StakingPool` ID `0xCANDIDATE_NODE_ID` (substitute the real ID before running anything).
- Operators have agreed to slash after observing the behavior and reaching consensus through the Walrus operator channels.
- The current epoch is `N`. Mainnet epochs are two weeks long, so there is generous time to collect votes.
- The voting operator's storage node has `StakingPool` ID `$NODE_ID` and shard count `W`.

The Mainnet object IDs you'll reference throughout:

```sh
$ WALRUS_PACKAGE=0x98da433aa0139512c210597b1c5e3df6cd121d8d77f8652691bb66fadfc8aa1b
$ SLASHING_MANAGER=0xfe343f7b72f67a1eca9bfc9dff0dac0520e11dca3bda5a0ea32816af6f722109
$ STAKING_OBJECT=0x10b9d30c28448939ce6c4d6c6e0ffce4a7f8a4ada8248bdad09ef8b70e4a3904
$ TREASURY_OBJECT=0x3a19b564728b56df21e0e2bd3582b2be00be992e27b44faf30611e15ae6eac91
$ CANDIDATE_NODE_ID=0xCANDIDATE_NODE_ID   # Replace with the real candidate ID.
$ NODE_ID=0xYOUR_NODE_ID                  # Replace with your own StakingPool ID.
```

## Day 1 of epoch N: first vote creates the proposal

The first operator to act submits the vote PTB from their `governance_authorized` wallet. The PTB constructs an `Authenticated` value tied to the sender, then passes it to `vote_for_slashing`.

```sh
$ sui client ptb \
    --move-call $WALRUS_PACKAGE::auth::authenticate_sender \
    --assign auth \
    --move-call $WALRUS_PACKAGE::slashing::vote_for_slashing \
        @$SLASHING_MANAGER @$STAKING_OBJECT auth @$NODE_ID @$CANDIDATE_NODE_ID \
    --gas-budget 100000000
```

After the transaction lands, the `SlashingManager` table has a new entry keyed by the candidate's node ID. The entry's `epoch` is `N`, the `voting_weight` equals the first voter's shard count `W`, and the `voters` set contains a single ID.

Confirm the new proposal by reading the `SlashingManager` object:

```sh
$ sui client object $SLASHING_MANAGER --json
```

The JSON output contains a `slashing_candidates` table. Look for an entry whose key matches `$CANDIDATE_NODE_ID`.

## Days 1 to 10 of epoch N: collect quorum

Other operators repeat the same vote PTB from their own governance wallets. Each new vote adds the voter's shard count to `voting_weight` and appends the voter's node ID to the `voters` set. The contract aborts with `EDuplicateVote` if an operator tries to vote twice on the same proposal in the same epoch.

Operators can monitor progress by re-running the read command above and observing `voting_weight` climb toward 667 (the quorum on a 1000-shard committee).

## Quorum reached: finalize the slashing

As soon as `voting_weight >= 667`, the proposal is finalizable. Operators pick one party to submit the execute call so the others do not waste gas on aborted races. The execute call does not take an `Authenticated` argument, so a plain `sui client call` works.

```sh
$ sui client call \
    --package $WALRUS_PACKAGE \
    --module slashing \
    --function execute_slashing \
    --args $SLASHING_MANAGER $STAKING_OBJECT $TREASURY_OBJECT $CANDIDATE_NODE_ID \
    --gas-budget 100000000
```

The transaction does three things atomically:

1. Removes the proposal from the `SlashingManager` table.
2. Extracts the full commission balance from the candidate's `StakingPool`.
3. Burns the extracted WAL through the `ProtectedTreasury`.

Verify the outcome:

```sh
$ sui client object $CANDIDATE_NODE_ID --json | grep -A1 commission
$ sui client object $TREASURY_OBJECT --json
$ sui client object $SLASHING_MANAGER --json
```

You should see the candidate's `commission` field at zero, the WAL `total_supply` reduced by the burned amount, and the candidate's entry removed from `slashing_candidates`.

## Cleanup of dangling proposals from prior epochs

If the operators do not reach 667 votes by the end of epoch `N`, the next vote in epoch `N+1` resets the proposal: the first vote in `N+1` creates a fresh proposal with `voting_weight` starting from zero, and all prior voters are discarded. The vote must start over.

If a proposal was abandoned and the operators chose not to restart it in the new epoch, the entry remains in the `SlashingManager` table until an explicit cleanup. Anyone can clear stale entries:

```sh
$ CANDIDATES='["0xCANDIDATE_NODE_ID","0xANOTHER_ID"]'
$ sui client call \
    --package $WALRUS_PACKAGE \
    --module slashing \
    --function cleanup_slashing_proposals \
    --args $SLASHING_MANAGER $STAKING_OBJECT "$CANDIDATES" \
    --gas-budget 100000000
```

The function removes only proposals whose stored epoch is strictly less than the current epoch. Active proposals are left untouched, and an entry that does not exist is silently skipped.

## Recap

The same three primitives cover the full lifecycle:

| Action  | Function                                  | Authorization        |
|---------|-------------------------------------------|----------------------|
| Vote    | `slashing::vote_for_slashing`             | `governance_authorized` on the voter's pool |
| Execute | `slashing::execute_slashing`              | Permissionless after quorum |
| Cleanup | `slashing::cleanup_slashing_proposals`    | Permissionless |

For abort codes, monitoring, FAQs, and the parallel with the contract upgrade vote, see the main [Slashing](/docs/operator-guide/storage-nodes/slashing) page.