validator voting period updates

anoma · Sep 4, 2024 · 52406b2 · 52406b2
1 parent cd05c96
commit 52406b2
Show file tree

Hide file tree

Showing 2 changed files with 8 additions and 2 deletions.
diff --git a/packages/docs/pages/users/governance/governance-actions.mdx b/packages/docs/pages/users/governance/governance-actions.mdx
@@ -70,7 +70,13 @@ namada client query-proposal-result --proposal-id $ID
 <Callout type="info">
 If the proposal has not passed, it will be rejected, and the code will not be executed.
 
-Another important note is that the voting period differs between validators and non-validators. The validators have a shorter voting period than the delegators. This is to ensure that the non-validators have enough time to vote on the proposals (so that the validators cannot vote in the last block against the non-validators preference). See the specs for more information.
+Another important note is that the voting period differs between validators and non-validators.
+Validators have a shorter voting period than delegators.
+This ensures that, if a delegator would like to vote differently than the validator to which they are delegated, there is a period during which they can change their vote to their own, rather than let the validator vote using their voting power.
+This prevents validators from voting in the last block of the voting period against the true preferences of their delegators.
+See the specs for more information.
+
+The output of `namadac query-proposal-result` will detail the latest epoch in which validators can vote on a given proposal.
 </Callout>
 
 ### Tally types

diff --git a/packages/docs/pages/users/governance/proposal-structure.mdx b/packages/docs/pages/users/governance/proposal-structure.mdx
@@ -44,7 +44,7 @@ A proposal author should manually set the following fields in the `proposal.json
 
 - `author`: the `tnam` address of `my-new-acc`;
 - `voting_start_epoch`: a future epoch in which you want the voting to begin.
-- `voting_end_epoch`: an epoch that is at least `min_proposal_voting_period` epochs further into the future than `voting_start_epoch` at which point no more votes are accepted.
+- `voting_end_epoch`: an epoch that is at least `min_proposal_voting_period` epochs further into the future than `voting_start_epoch`, at which point no more votes are accepted.
 - `activation_epoch`: an epoch that is at least `min_proposal_grace_epochs` epochs further into the future than `voting_end_epoch`, at which any associated WASM code will be executed.
 
 The `data` field and its contents are dependent on the [type of proposal](./proposal-types.mdx) being submitted.