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.
I do recognize its late in the game to bring it up, but felt worthwhile either way
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.
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 =)
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.
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?
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.
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.
@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.
I’d like to refresh the discussion here just ahead of v0.44.0 and summarize what seems to be the latest consensus on the initial parameter values. The current values as I see them are detailed in the following .toml style:
# General protocol parameters.
[parameters]
native_token = "NAM"
is_native_token_transferable = false # Phase 5: turn to true
min_num_of_blocks = 2700 # assume 6 second blocks and 6 hour epochs
max_tx_bytes = 1048576
max_proposal_bytes = 6291456
vp_allowlist = [] # Fill in before mainnet
tx_allowlist = [] # Fill in before mainnet
implicit_vp = "vp_implicit"
epochs_per_year = 1460 # assumes 6 hour epochs
masp_epoch_multiplier = 4
max_block_gas = 5_000_000
masp_fee_payment_gas_limit = 250_000 # added in v0.44.0
gas_scale = 10_000 # added in v0.44.0
# Map of the cost per gas unit for every token allowed for fee payment
[parameters.minimum_gas_price]
nam = "0.00001" # assume max gas per block of 5M, costs 50 NAM to fill block
# Proof of stake parameters.
[pos_params]
max_validator_slots = 255
pipeline_len = 2
unbonding_len = 53
tm_votes_per_token = "1"
block_proposer_reward = "0.125"
block_vote_reward = "0.1"
max_inflation_rate = "0.0" # Phase 2: turn to 5%
target_staked_ratio = "0.4"
duplicate_vote_min_slash_rate = "0.001"
light_client_attack_min_slash_rate = "0.001"
cubic_slashing_window_length = 1
validator_stake_threshold = "1000000000" # 1000 NAM
liveness_window_check = 10_000 # assuming 6s blocks, the window for evaluating is 16.67 hours
liveness_threshold = "0.1" # assuming 6s blocks, must sign 10% in a 16.67 hour window
rewards_gain_p = "0.25" # will check if recalibration needed
rewards_gain_d = "0.25" # will check if recalibration needed
# Governance parameters.
[gov_params]
min_proposal_fund = 2000 # 2000 NAM deposited to make gov proposal
max_proposal_code_size = 1_000_000 // in bytes
min_proposal_voting_period = 12 # Phase 5: turn to 29
max_proposal_period = 84 # 21 day voting
max_proposal_content_size = 10000
min_proposal_grace_epochs = 0 # Phase 5: turn to 8
max_proposal_latency = 8 # max 2 day delay between launching proposal and voting start
# Public goods funding parameters
[pgf_params]
stewards = []
pgf_inflation_rate = "0.0" # Phase 2: turn to 5%
stewards_inflation_rate = "0.0" # Phase 2: turn to 0.5%
maximum_number_of_stewards = 1 # added in v0.44.0
# IBC parameters
[ibc_params]
default_mint_limit = "0" # Phase 3: NEED TO COME UP WITH VALUE
default_per_epoch_throughput_limit = "0" # Phase 3: NEED TO COME UP WITH VALUE
There are three new parameters introduced in v0.44.0: masp_fee_payment_gas_limit , gas_scale, and maximum_number_of_stewards. The values of the first two were recommended by the engineer responsible for the gas mechanism. The maximum number of stewards at any given time is proposed to be 1 to begin the network. Adding another PGF steward with a gov proposal down the line would just also require increasing the max_number_of_stewards.
Please feel free to continue the discussion and express agreement or disagreement with the current params.
Yes, thanks for confirming, this should be added in the latest release so the minimum commission rate of 5% is enforced from the beginning.
The stake is very sticky so if the min 5% fee is not enforced from the beginning every validator will want to put 0% fee to attract the most stake before a governance proposal to enforce the min 5% fee. There is already a huge unfair marketing advantage for many weeks for those validators advertising a fee below 5% currently in the pre-genesis stage 2. I’m amazed that nobody at Heliax or Luminara had planned already this min 5% fee in the code to avoid this current unfair marketing advantage, from what I read before it seemed obvious that it would be included but such an important parameter was finally overlooked. I hope any pre-genesis staking dashboard shows those validators with a fee below 5% currently as 5% and a clear message that a min 5% fee is enforced. Also until the min 5% fee was enforced in the Cosmos Hub for example, several previous proposals to enforce the minimum fee failed. This happened obviously because many delegators want to have 0% fee to get all the rewards so a very large % of delegators will vote against enforcing a min fee min. The probability of a governance proposal to enforce the min 5% fee failing is very high actually, because not only all validators with a fee below 5% and accumulating unfairly VP before the proposal will vote against but also a large % of delegators. The min 5% fee must be enforced in the protocol since the beginning @cwgoes
But why if the code is ready for the min 5% fee? If there are still 2 weeks left for pre-genesis phase 2 surely those validators with a fee below 5% have time to resubmit the txs?
For validators it is a very big deal, it means potentially losing a huge amount of stake and delegators that may go to 0% fee validators (and this will be very noticeable already once the dashboards are ready and if not clearly indicated about the min 5% fee) and then if a 5% min fee is enforced later given that the stake is sticky it could remain in those previous 0% fee validators. This will be greatly exacerbated by the fact that initially the staking ratio will be low and hence the APR higher meaning even more incentives to choose 0% fee validators
Thanks @brentstone! I think I can say that we (Knowable) are ready to proceed with these parameters.
Noting that:
max_proposal_code_size (cc @Rigorous) turns out to be what we intended, being denominated in bytes in the code (but good catch, Rigorous! the docstring had mistakenly noted kb).
Governance voting period would only be 3 day minimum voting at launch, which we think that should later increase to 7.25 days at the same time that transfers are enabled.
Governance grace period would be 0 at launch, which we think that should later increase to 2 days at the same time that transfers are enabled.
The max_block_gas will be 15_000_000 instead of 5_000_000. This is needed to pass governance proposals with wasm code such as the proposals to transition between phases of mainnet.
good catch