last changes

docs/docs/adrs/adr-018-fault-resolutions.md

@@ -13,49 +13,59 @@ Proposed
 
 ## Context
 
-Partial Set Security ([PSS](./adr-015-partial-set-security.md)) allows a subset of a provider chain's validator set to secure a consumer chain. While this shared security scheme has many advantages, it comes with a pitfall known as the [subset problem](https://informal.systems/blog/replicated-vs-mesh-security#risks-of-opt-in-security-also-known-as-ics-v-2). This problem arises when a malicious majority of validators from the provider chain collude and misbehave on a consumer chain. This threat is particularly relevant for Opt-in chains since they might be secured by a relatively small subset of the provider's validator set.  
+Partial Set Security ([PSS](./adr-015-partial-set-security.md)) allows a subset of a provider chain's validator set to secure a consumer chain.
+ While this shared security scheme has many advantages, it comes with a risk known as the
+ [subset problem](https://informal.systems/blog/replicated-vs-mesh-security#risks-of-opt-in-security-also-known-as-ics-v-2).
+ This problem arises when a malicious majority of validators from the provider chain collude and misbehave on a consumer chain.
+ This threat is particularly relevant for Opt-in chains since they might be secured by a relatively small subset of the provider's validator set.  
 
 In cases of collusion, various types of misbehaviour can be performed by the validators, such as:
 
--Incorrect executions to break the rules of the protocol and steal funds.
--Liveness attacks to halt the chain or censor transactions.
--Oracle attacks to falsify information used by the chain logic.
+- Incorrect executions to break protocol rules in order to steal funds.
+- Liveness attacks to halt the chain or censor transactions.
+- Oracle attacks to falsify information used by the chain logic.
 
 
-Currently, these type of attack aren't handled by the protocol, leaving the malicious validators unpunished.
+Currently, these type of attack aren't handled in PSS, leaving the malicious validators unpunished.
 
-A potential solution is to use fraud proofs. This technology allows proving incorrect state transitions of a chain without a full node. However, this is a complex technology, and there is no framework that works for Cosmos chains to this day.
+A potential solution is to use fraud proofs. This technology allows proving incorrect state transitions of a chain without a full node.
+ However, this is a complex technology, and there is no framework that works for Cosmos chains to this day.
 
 
 To address this risk in PSS, a governance-gated slashing solution can be used until fraud proof technology matures.
 
 
-This ADR proposes a fault resolution mechanism, which is a type of governance proposal that victims of faults can use to vote on the slashing of validators that misbehave on Opt-in consumer chains.
+This ADR proposes a fault resolution mechanism, which is a type of governance proposal that victims of faults can use to vote on the
+ slashing of validators that misbehave on Opt-in consumer chains.
 
-In what follows, we describe the implementation of a fault resolution mechanism that handles incorrect executions on consumer chains, as a first iteration.
+In what follows, we describe the implementation of a fault resolution mechanism that handles incorrect executions on consumer chains,
+ as a first iteration.
 
 
 ## Decision
 
-The proposed solution introduces a new `consumer-fault-resolution` governance proposal type to the `provider` module, which allows validators to be penalised for committing faults on an Opt-in consumer chain.
+The proposed solution introduces a new `consumer-fault-resolution` governance proposal type to the `provider` module, which allows
+ validators to be penalised for committing faults on an Opt-in consumer chain.
 
-If such a proposal passes, the proposal handler tombstones all the validators listed in the proposal and slashes them by a predefined amount or the default value used for double-sign infractions.
+If such a proposal passes, the proposal handler tombstones all the validators listed in the proposal and slashes them by a predefined
+ amount or the default value used for double-sign infractions.
 
 The proposal has the following fields:
 
--**Description**: This field should be filled with a fault definition describing the type of misbehavior that the validators executed on a Opt-in consumer chain. A fault definition should precisely describe how an attack was performed and why it is eligible as a slashable fault.
--**Consumer Chain**: The chain that the fault was related to.
--**Validators**: The list of all the validators to be slashed.
+- **Description**: This field should be filled with a fault definition describing the type of misbehavior that the validators executed
+ on a Opt-in consumer chain. A fault definition should precisely describe how an attack was performed and why it is eligible as a slashable fault.
+- **Consumer Chain**: The chain that the fault was related to.
+- **Validators**: The list of all the validators to be slashed.
 
-In addition, in order to prevent spamming, users are required to pay a fee of `250ATOM` to submit a fault resolution to the provider.
+In addition, in order to prevent spamming, users are required to pay a fee of `100ATOM` to submit a fault resolution to the provider.
 
 ### validations
 
 The submission of a fault resolution fails if any of the following conditions are not met:
 
--the consumer chain is an Opt-in chain
--all listed validators were opted-in to the consumer chain in the past unbonding-period
--the minimum fee is provided
+- the consumer chain is an Opt-in chain
+- all listed validators were opted-in to the consumer chain in the past unbonding-period
+- the `100ATOM` fee is provided
 
 ### additional considerations
 
@@ -67,15 +77,16 @@ to unbond in order to not be punished.
 
 ### Positive
 
--Provide the ability to slash and tombstone validators for committing incorrect executions on Opt-in consumer chains.
+- Provide the ability to slash and tombstone validators for committing incorrect executions on Opt-in consumer chains.
 
 ### Negative
 
--Assuming that malicious validators unbond immediately after misbehaving, a fault resolution has to be submitted within a maximum of two weeks in order to slash the validators.
+- Assuming that malicious validators unbond immediately after misbehaving, a fault resolution has to be submitted within a maximum
+ of two weeks in order to slash the validators.
 
 ### Neutral
 
--Fault definitions need to have a clear framework in order to avoid debates about whether or not an attack has actually take place.  
+- Fault definitions need to have a clear framework in order to avoid debates about whether or not an attack has actually take place.  
 
 ## References