Mainnet parameter discussions: Knowable's proposal

Mainnet Ops Parameters
81

Documentation on governance tally types here notes

Default proposals require at least 2/3 of the total active voting power to have voted AND the yay voting power must be at least 2/3 of the combined yay + nay voting power.

2/3 quorum is higher than comparable chains (ex: 20% quorum on Osmosis, 40% quorum on Cosmos). Given governance is in the critical path for launching the chain, choosing a more conservative quorum in line with comparable chains would reduce the odds of a stunted launch due to a lack of governance participation.

2 Likes
82

thanks for flagging this! @brentstone @cwgoes @citizenweb3 thoughts?

the issue i see is that any non-PGF proposal can execute arbitrary wasm, so there need to be high thresholds because of how much power they have

but what if there are more mundane proposals? like changing a parameter

if i want to make a social signalling proposal, i suppose i would need to use an RPG proposal that allocates 0 NAM as a work-around…

i made some feature suggestions, but i think most of them will need to wait until after mainnet: Issues · anoma/namada · GitHub

2 Likes
83

I do recognize its late in the game to bring it up, but felt worthwhile either way :slight_smile:

And could be supportive of higher quorums for arbitrary wasm execution, while relaxing them for ie. parameter changes. Backing a signaling proposal into an RPG proposal simply due to its ergonomics doesn’t feel ideal.

1 Like
84

I dont think its too late. I would argue that governance can (and should) be developed and upgraded as the chain growths / shrinks. Its purpose, amongst other things, is to defend the chains interests. So its never too late - its on time =)

2 Likes
85

What about unstake period? 14 days?

1 Like
86

@Rigorous noted that max_proposal_code_size is denominated in kb, not byes, and should be changed to 1000

thanks for checking these, Rigorous :heart:

87

Thanks for bringing this up @mike-u410 - I think those parameter choices haven’t been considered recently. Personally, I think a quorum of 2/5 (40% - same as Cosmos) voting power would be fine to start.

3 Likes
88

That feels like the right balance between ‘de-risking launch phase delays’ and ‘don’t allow folks to easily execute arbitrary wasm’ - I’m supportive within the current design! What’s next?

2 Likes
89

okay i’ve requested that all three proposal types have a hard-coded quorum of 40% for mainnet: Hard-code all governance proposal types to be 40% · Issue #3683 · anoma/namada · GitHub

but we would like to re-evaluate the proposal types soon after mainnet, and perhaps we can also revisit what’s parameterized at that time

thank you, @mike-u410 :raised_hands: good catch

2 Likes
90

In order to be able to have more control over the pace at which we advance through the phases of mainnet, I’d also like to propose some governance parameter revisions specifically for the Mainnet Phases, before returning them the original proposed parameters. We could do this using an omnibus proposal when turning on transfers in Phase 5.

At launch → 0-day grace period
at Phase 5 (transfers enabled) → 2-day grace period

At launch → minimum 3-day voting period (validators getting minimum of 2 days for voting)
at Phase 5 → minimum 7.25-day voting period (validators getting minimum of 5 days for voting)

By omnibus, I mean a single proposal could be used to update the grace period, minimum voting period, and to turn transfers on.

3 Likes
91

I think starting with some parameters to expedite the governance process as we move from Phase 1 to 5 is a good idea. I’ve opened two small PRs that people can check out and comment on.

  1. change quorum for default governance proposals from 2/3 → 40%: Change default proposal quorum by brentstone · Pull Request #3703 · anoma/namada · GitHub
  2. change governance min voting period and min grace epochs as part of the Phase 4 → 5 wasm that enables NAM transfers (Gavin’s “omnibus” proposal): Refactor + Add gov param updates to Phase 5 transition by brentstone · Pull Request #10 · anoma/namada-governance-upgrades · GitHub
4 Likes
92

what’s the unstaking buffer is set at?

93

@Momonosukke the unstaking buffer - the time it takes for unbonded tokens to be withdrawable - is planned to be about 14 days, assuming roughly 6 hour epochs.

The pipeline length is 2 epochs, the unbonding length is 53 epochs, and the cubic slashing window width is 1 epoch. An unbond tx then requires waiting for all of these (56 epochs in total) until the tokens can be withdrawn.

2 Likes