# Mainnet parameter discussions: Knowable's proposal **URL:** \ **Category:** Parameters\ **Created:** [26 June 2024 02:20 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753 "2024-06-26T02:20:56Z")\ **Posts on this page:** 20\ **Page:** 5
**Author:** ![mike-u410](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/mike-u410/32/489_2.png) [@mike-u410](https://forum.namada.net/u/mike-u410)\ **Post date:** [16 August 2024 18:29 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/81 "2024-08-16T18:29:54Z")
Documentation on governance tally types [here](https://docs.namada.net/users/governance/governance-actions#tally-types) 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. ---
**Author:** ![Gavin](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/gavin/32/16_2.png) [@Gavin](https://forum.namada.net/u/Gavin)\ **Post date:** [19 August 2024 13:53 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/82 "2024-08-19T13:53:27Z")
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](https://github.com/anoma/namada/issues/created_by/gavinly) ---
**Author:** ![mike-u410](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/mike-u410/32/489_2.png) [@mike-u410](https://forum.namada.net/u/mike-u410)\ **Post date:** [19 August 2024 16:06 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/83 "2024-08-19T16:06:41Z")
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. ---
**Author:** ![citizenweb3](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/citizenweb3/32/882_2.png) [@citizenweb3](https://forum.namada.net/u/citizenweb3)\ **Post date:** [19 August 2024 16:32 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/84 "2024-08-19T16:32:38Z")
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 =) ---
**Author:** ![encipher](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/encipher/32/76_2.png) [@encipher](https://forum.namada.net/u/encipher)\ **Post date:** [20 August 2024 05:16 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/85 "2024-08-20T05:16:17Z")
What about unstake period? 14 days? ---
**Author:** ![Gavin](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/gavin/32/16_2.png) [@Gavin](https://forum.namada.net/u/Gavin)\ **Post date:** [21 August 2024 03:13 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/86 "2024-08-21T03:13:42Z")
@Rigorous noted that `max_proposal_code_size` is denominated in kb, not byes, and should be changed to `1000` thanks for checking these, Rigorous ❤ ---
**Author:** ![cwgoes](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/cwgoes/32/39_2.png) [@cwgoes](https://forum.namada.net/u/cwgoes)\ **Post date:** [21 August 2024 08:20 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/87 "2024-08-21T08:20:08Z")
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. ---
**Author:** ![mike-u410](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/mike-u410/32/489_2.png) [@mike-u410](https://forum.namada.net/u/mike-u410)\ **Post date:** [21 August 2024 16:10 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/88 "2024-08-21T16:10:06Z")
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? ---
**Author:** ![Gavin](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/gavin/32/16_2.png) [@Gavin](https://forum.namada.net/u/Gavin)\ **Post date:** [22 August 2024 01:51 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/89 "2024-08-22T01:51:37Z")
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](https://github.com/anoma/namada/issues/3683) but we would like to [re-evaluate the proposal types](https://github.com/anoma/namada/issues/created_by/gavinly) soon after mainnet, and perhaps we can also revisit what’s parameterized at that time thank you, @mike-u410 🙌 good catch ---
**Author:** ![Gavin](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/gavin/32/16_2.png) [@Gavin](https://forum.namada.net/u/Gavin)\ **Post date:** [22 August 2024 02:01 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/90 "2024-08-22T02:01:49Z")
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. ---
**Author:** ![brentstone](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/brentstone/32/464_2.png) [@brentstone](https://forum.namada.net/u/brentstone)\ **Post date:** [27 August 2024 22:26 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/91 "2024-08-27T22:26:29Z")
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](https://github.com/anoma/namada/pull/3703) 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](https://github.com/anoma/namada-governance-upgrades/pull/10) ---
**Author:** ![Momonosukke](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/momonosukke/32/504_2.png) [@Momonosukke](https://forum.namada.net/u/Momonosukke)\ **Post date:** [3 September 2024 15:00 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/92 "2024-09-03T15:00:52Z")
what’s the unstaking buffer is set at? ---
**Author:** ![brentstone](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/brentstone/32/464_2.png) [@brentstone](https://forum.namada.net/u/brentstone)\ **Post date:** [3 September 2024 19:05 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/93 "2024-09-03T19:05:27Z")
@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. ---
**Author:** ![brentstone](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/brentstone/32/464_2.png) [@brentstone](https://forum.namada.net/u/brentstone)\ **Post date:** [26 September 2024 01:35 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/94 "2024-09-26T01:35:55Z")
Hello everyone! 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: ```auto # 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. ---
**Author:** ![CosmicValidator](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/cosmicvalidator/32/274_2.png) [@CosmicValidator](https://forum.namada.net/u/CosmicValidator)\ **Post date:** [26 September 2024 08:42 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/95 "2024-09-26T08:42:36Z")
> [@brentstone](#): > > `min_commission_rate = "0.05" # added in v0.44.0` 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 ---
**Author:** ![brentstone](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/brentstone/32/464_2.png) [@brentstone](https://forum.namada.net/u/brentstone)\ **Post date:** [26 September 2024 08:56 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/96 "2024-09-26T08:56:13Z")
Whoops, left that in there mistakenly in my first post (and now edited and removed). Like I mentioned in discord, this is not planned for pre-genesis. ---
**Author:** ![CosmicValidator](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/cosmicvalidator/32/274_2.png) [@CosmicValidator](https://forum.namada.net/u/CosmicValidator)\ **Post date:** [26 September 2024 09:00 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/97 "2024-09-26T09:00:00Z")
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 ---
**Author:** ![Gavin](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/gavin/32/16_2.png) [@Gavin](https://forum.namada.net/u/Gavin)\ **Post date:** [26 September 2024 20:02 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/98 "2024-09-26T20:02:47Z")
Thanks @brentstone! I think I can say that we (Knowable) are ready to proceed with these parameters. Noting that: 1. 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). 2. 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. 3. 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. Looking forward to progress with “[Preparing to kick off shielded set rewards](https://forum.namada.net/t/preparing-to-kick-off-shielded-set-rewards/836)”! ---
**Author:** ![brentstone](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/brentstone/32/464_2.png) [@brentstone](https://forum.namada.net/u/brentstone)\ **Post date:** [19 October 2024 01:30 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/99 "2024-10-19T01:30:40Z")
Wanted to make a small update on parameter values, as there is one that will need to be changed with respect to [Mainnet parameter discussions: Knowable's proposal - #94 by brentstone](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/94). 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. ---
**Author:** ![Rigorous](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/rigorous/32/397_2.png) [@Rigorous](https://forum.namada.net/u/Rigorous)\ **Post date:** [20 October 2024 13:39 UTC](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753/100 "2024-10-20T13:39:23Z")
How was the 15 million gas units benchmarked? I managed to submit a proposal with WASM with less than 200,000 gas units. > > > v0.41.0 > > \`namadac init-proposal --data-path tx\_proposal\_with\_wasm.json\` > > \`\`\`… > Last committed epoch: 4736 > Submitting a tx to reveal the public key for address tnam1qz7d8ptgclwfap9rdkdp2hpuyva0czkkdyheyllr... > Enter your decryption password: > Transaction added to mempool. > Transaction hash: 099CC64B10224193B2BC50D981FC5DC7B7644E766D03F082FEFDD13A9E01B395 > Transaction 7009DB08D9E7BD8848E991FA9D538636BC6EC2CA405AE2D0CF4D849E7D90260A was successfully applied at height 236771, consuming 6568 gas units. > Transaction added to mempool. > Transaction hash: 3CB168CCBFE4B5E187CBDE14197CE50121A24B7391C1808E97CC0A9A5536D38B > Transaction 7201A498D0591F535EEEFB4FCF82B34C439D95D94E22F939528F31F3D0478FAC failed. > Details: { > "batch": { > "7201A498D0591F535EEEFB4FCF82B34C439D95D94E22F939528F31F3D0478FAC": { > "Err": "Gas error: RuntimeError: Storage error: Transaction gas limit exceeded" > } > }, > "info": "Error trying to apply a transaction: Gas error: RuntimeError: Storage error: Transaction gas limit exceeded", > "log": "", > "height": 236772, > "hash": \[ > 60, > 177, > 104, > 204, > 191, > 228, > 181, > 225, > 135, > 203, > 222, > 20, > 25, > 124, > 229, > 1, > 33, > 162, > 75, > 115, > 145, > 193, > 128, > 142, > 151, > 204, > 10, > 154, > 85, > 54, > 211, > 139 > \], > "code": "WasmRuntimeError", > "gas\_used": 108517 > } > \`\`\` > > When adding \`--gas-limit 200000\` : > > \`\`\` > Transaction 45C779958D5B2D3EE349B598087D3F79A6515FD7CDB8E773B6863520936F9D23 was successfully applied at height 237159, consuming 112266 gas units. > \`\`\` [Previous page](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753.md?page=4) [Next page](https://forum.namada.net/t/mainnet-parameter-discussions-knowables-proposal/753.md?page=6)