diff --git a/docs/docs/features/partial-set-security.md b/docs/docs/features/partial-set-security.md index 6f8cb3897e..a2edbbb15d 100644 --- a/docs/docs/features/partial-set-security.md +++ b/docs/docs/features/partial-set-security.md @@ -24,5 +24,5 @@ Both Opt In and Top N chains currently require a governance proposal to be added For Top N chains, this is also the long term vision for how they are launched. -For Opt In chains, this is a temporary measure to prevent issues around chain ID squatting. Eventually, the plan is to allow launching Opt In chains permissionlessly without going through governance, with quality control being handled by the market of validators deciding which chains they would like to validate on. +For Opt In chains, this is a temporary measure to prevent issues around chain ID squatting, i.e. someone could spuriously register many desirable chain IDs of upcoming consumer chain and simply deny legitimate consumer chains from using them. Eventually, the plan is to allow launching Opt In chains permissionlessly without going through governance, with quality control being handled by the market of validators deciding which chains they would like to validate on. ::: diff --git a/docs/docs/features/power-shaping.md b/docs/docs/features/power-shaping.md index 44b7582c98..9884c6184b 100644 --- a/docs/docs/features/power-shaping.md +++ b/docs/docs/features/power-shaping.md @@ -7,13 +7,21 @@ These are: 1) **Capping the size of the validator set**: The consumer chain can specify a maximum number of validators it wants to have in its validator set. This can be used to limit the number of validators in the set, which can be useful for chains that want to have a smaller validator set for faster blocks or lower overhead. -*Note*: This is only applicable to Opt In chains (chains with Top N = 0). +:::info +This is only applicable to Opt In chains (chains with Top N = 0). +::: 1) **Capping the fraction of power any single validator can have**: The consumer chain can specify a maximum fraction of the total voting power that any single validator in its validator set should have. -This is a security measure with the intention of making it harder for a single large validator to take over a consumer chain. This mitigates the risk of an Opt In chain with only a few validators being dominated by a validator with a large amount of voting power opting in. +This is a security measure with the intention of making it harder for a single large validator to take over a consumer chain. This mitigates the risk of an Opt In chain with only a few validators being dominated by a validator with a large amount of stake opting in. For example, setting this fraction to e.g. 33% would mean that no single validator can have more than 33% of the total voting power, and thus there is no single validator who would stop the chain by going offline. -Note that this is a soft cap, and the actual power of a validator can exceed this fraction if the validator set is small (e.g. there are only 3 validators and the cap is 20%). +:::info +This is a soft cap, and the actual power of a validator can exceed this fraction if the validator set is small (e.g. there are only 3 validators and the cap is 20%). +::: +:::info +Rewards are distributed proportionally to validators with respect to their capped voting power on the consumer, +not their total voting power on the provider. +::: 1) **Allowlist and denylist**: The consumer chain can specify a list of validators that are allowed or disallowed from participating in the validator set. If an allowlist is set, all validators not on the allowlist cannot validate the consumer chain. If a validator is on both lists, the denylist takes precedence, that is, they cannot validate the consumer chain. If neither list is set, all validators are able to validate the consumer chain. :::warning diff --git a/docs/docs/frequently-asked-questions.md b/docs/docs/frequently-asked-questions.md index e31123a9cf..f648f8eac6 100644 --- a/docs/docs/frequently-asked-questions.md +++ b/docs/docs/frequently-asked-questions.md @@ -90,7 +90,7 @@ To become a consumer chain use this [checklist](./consumer-development/onboardin Currently supported versions: -- Hermes 1.4.1 +- Hermes 1.8.0 ## How does key delegation work in ICS? @@ -117,7 +117,7 @@ Yes, see the [Key Assignment Guide](./features/key-assignment.md) for more infor ## Can validators assign a consensus key during the voting period for a consumer-addition proposal if they are not in the top N? Yes. -## Can validators opt in to an Opt-in chain after its consumer-addition proposal voting period is over but before the spawn time? +## Can validators opt in to an Opt-in or Top N chain after its consumer-addition proposal voting period is over but before the spawn time? Yes. ## Can validators opt in to an Opt-in chain after the spawn time if nobody else opted in? @@ -129,9 +129,3 @@ Yes, the consumer chain will halt with an ERR CONSENSUS FAILURE error after the ## Can validators set a commission rate for chains they have not opted in to? Yes, and this is useful for validators that are not in the top N% of the provider chain, but might move into the top N% in the future. By setting the commission rate ahead of time, they can make sure that they immediately have a commission rate of their choosing as soon as they are in the top N%. - -## On how many consumer chains can a validator opt-in at the same time? - -There is no limit to the number of consumer chains a validator can opt in to. -However, some consumer chains may restrict the validators actually getting to validate there, for example consumer chains can set up denylists to stop certain validators from validating there. -See the [Power Shaping](./features/power-shaping.md) section for more information.