# Offence management

**URL:** https://forum.duniter.org/t/offence-management/10041
**Category:** Ğ1v2 protocol
**Tags:** babe-grandpa
**Created:** [21 November 2022 11:04 UTC](https://forum.duniter.org/t/offence-management/10041 "2022-11-21T11:04:05Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![HugoTrentesaux](https://forum.duniter.org/user_avatar/forum.duniter.org/hugotrentesaux/32/6396_2.png) [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [21 November 2022 11:04 UTC](https://forum.duniter.org/t/offence-management/10041/1 "2022-11-21T11:04:05Z")

</div>

We have to choose a mechanism to manage offense to ImOnline/BABE/GRANDPA.

I think we can adopt the following simple rules:

- ImOnline offence can happen to anybody because of electricity or network outage, we should immediately trigger the authority removal from the set of authorities
- BABE/GRANDPA offence can be produced by an attacker or by mistake (multiple validators with same keys), these offence are more problematic and should lead the author to enter a blacklist

The questions are:

- do we want to increase the penalty for ImOnline offence for example with a blacklist of fees? or do we keep it for human governance (we can exclude someone from the smith if he is offline too often)
- what are the mechanisms to get out of the blacklist? (decision of technical committee… + fees…)

---

<div class="post-metadata">

### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois)
#### Post date: [21 November 2022 15:14 UTC](https://forum.duniter.org/t/offence-management/10041/2 "2022-11-21T15:14:07Z")

</div>

Let’s keep it simple for a first iteration, i.e. what we agreed on during the hackathon in Bordeaux:

- ImOnline offence: just auto goOffline. The concerned member will be able to redo goOnline whenever he wants.
- BABE/GRANDPA offence: auto goOffline AND push the member idty index in a blacklist that will prevent him from doing goOnline again. The removal of this blacklist then requires a manual action of the on-chain governance.

---

<div class="post-metadata">

### Author: ![Moul](https://forum.duniter.org/user_avatar/forum.duniter.org/moul/32/9145_2.png) [@Moul](https://forum.duniter.org/u/Moul)
#### Post date: [20 November 2024 16:41 UTC](https://forum.duniter.org/t/offence-management/10041/3 "2024-11-20T16:41:49Z")

</div>

Thanks for this post! Following sentence made me think about this case, I haven’t though about earlier.

> [@HugoTrentesaux](#):
>
> BABE/GRANDPA offence can be produced by an attacker or by mistake (multiple validators with same keys)

As a smith, we should not set up more than one smith/validator node? Of course, it make sense, since it would disturb BABE/GRANDPA algorithm. Coming from v1 ecosystem, this is an interesting point to have in mind. I think this information is relevant to be added to the smith license/charter.

> [@elois](#):
>
> BABE/GRANDPA offence: auto goOffline AND push the member idty index in a blacklist that will prevent him from doing goOnline again. The removal of this blacklist then requires a manual action of the on-chain governance.

After how many offences, does the smith gets in the black list?