Parameter Changes

What Parameters Can Be Changed?

Any parameter exposed by a module's parameter subspace can be targeted by a Parameter Change proposal. Common examples on AIOZ Network include staking (e.g. MaxValidators, AcceptAllValidators), slashing, distribution, and mint (inflation-related parameters).

AIOZ also runs a separate bonus module for an additional block reward on top of standard mint inflation, confirmed as two distinct modules by querying both directly against a live node. Check what a given module exposes before drafting a proposal:

aiozd query params subspace <subspace> <key>

What Are the Current Parameter Values?

Always confirm the live value on mainnet immediately before submitting. Parameters can change between when you draft a proposal and when it goes live:

aiozd query staking params
aiozd query slashing params
aiozd query distribution params
aiozd query mint params
aiozd query bonus params

ℹ️

All five commands above were run directly against a live mainnet node while writing this page and returned real data. Note that the public LCD's /cosmos/mint/v1beta1/params REST route specifically returns Not Implemented even though aiozd query mint params works fine, a gap in that one REST route, not in the module itself.

Why Create a Parameter Change Proposal?

Parameter changes are the mechanism for tuning the network without a full software upgrade. Adjusting the active validator set size, unbonding time, slashing penalties, or block reward shares are all changes the community can make through a vote rather than a coordinated binary release and a scheduled restart.

That's a meaningfully lower bar: a parameter change can be proposed, voted on, and take effect within days, while a software upgrade needs a new binary built, tested, distributed to every validator, and applied at a coordinated height.

That lower bar cuts both ways. It's also easier to under-think a parameter change than a software upgrade, precisely because there's no build-and-test cycle forcing a second look before it goes live.

Risks in Parameter Change Proposals

⚠️

Parameter values submitted in a proposal are evaluated at execution time but not validated ahead of submission. A wrong type or an out-of-bounds value can still be submitted and passed. There is no dry-run; testing the exact proposal JSON on testnet first is the only real safety net.

A parameter change that looks safe in isolation can still have network-wide side effects. For example, raising MaxValidators changes the economics of the entire active set, not just the newly-admitted validators: existing validators now split rewards and delegations across more competitors, and the bonded-stake threshold to make the active set at all shifts too.

Model the downstream effect on every existing participant, not just the parameter itself, before proposing a change.

It's also worth being explicit in the proposal description about what you checked and what you didn't. A reviewer who sees "verified against current MaxValidators behavior, did not model impact on commission rates" can decide for themselves whether that gap matters; a reviewer who only sees the raw JSON has to reconstruct that analysis themselves or take it on faith.

Real Example

AIOZ Network's first mainnet proposal was a Parameter Change proposal, and it remains the clearest real illustration of the type:

Proposal ID: 1
Title: Disable AcceptAllValidators
Description: Change staking params
Change: subspace: staking, key: AcceptAllValidators, value: false
Result: Passed

{
  "title": "Disable AcceptAllValidators",
  "description": "Change staking params",
  "changes": [
    {
      "subspace": "staking",
      "key": "AcceptAllValidators",
      "value": false
    }
  ],
  "deposit": "10000000000000000000000attoaioz"
}

The 10000000000000000000000attoaioz (10,000 AIOZ) deposit above is the actual total_deposit recorded for this proposal on mainnet, not a template placeholder; it exceeded whatever min_deposit was in effect back in December 2021, which has since changed. Always check the live value (see above) rather than assuming this figure still applies.

Once AcceptAllValidators is false, new validators can no longer self-register through an open create-validator transaction and need a separate governance-approved path to join the active set instead.

PreviousCommunity Pool Spend NextSoftware Upgrade