Off-Chain Proposal Process

Engage Directly With the Voting Community and Seek Feedback

Voting power on AIOZ Network is held by bonded validators, with delegators inheriting their validator's vote unless they override it themselves. That means the people whose support actually decides quorum and outcome are a relatively small, identifiable group: active validators and the delegators large enough to move the outcome on their own.

Reach them directly rather than assuming a proposal will be discovered on-chain:

• AIOZ Network Community Telegram (opens in a new tab)
• AIOZ Network on X (opens in a new tab)
• Validator operators directly, since they ultimately cast the bulk of the voting power

It's worth deliberately seeking out people who might disagree with you, not just the people you already expect to be supportive. A proposal that has only been reviewed by people who already like the idea hasn't actually been tested. If a validator tells you the change is a bad idea, that's more useful at this stage than another "sounds good."

Stage 1: Your Idea

Not Yet Confident About Your Idea?

If you're still exploring whether an idea is worth pursuing, say so explicitly when you raise it. Ask open questions instead of presenting conclusions, and expect the idea to change shape based on what validators and delegators tell you about technical feasibility, cost, or prior context you may be missing.

It's normal for an idea to look completely different after a week of this than it did at the start; that's the process working, not a sign you started with a bad idea.

At this stage, it's also worth roughly figuring out which proposal type you're even talking about. A vague complaint ("validators are too concentrated") can turn into a Parameter Change (adjusting MaxValidators or commission bounds), or a Text proposal (just recording that the community wants this addressed), depending on how far you're willing to take it.

Confident With Your Idea?

Once you believe the idea is sound, start writing it down in more concrete terms: what exactly changes, for whom, and why now. Keep circulating this written version in the community channels above rather than moving straight to a formal draft.

A second round of scrutiny at this stage catches problems a first casual mention would not, and it's much cheaper to discover a flaw here than after a deposit is already on the line.

Are You Ready to Draft a Governance Proposal?

Move to drafting once you can answer, without hand-waving:

• What is being asked for, phrased unambiguously enough that a validator with no prior context could vote on it correctly
• Why the change is needed, and why now rather than later
• Who is affected and how, including anyone who stands to be worse off
• What the proposal type should be: Text, Parameter Change, Community Pool Spend, or Software Upgrade
• Roughly who you expect to vote Yes, and whether that's enough bonded stake to plausibly clear quorum

If you can't answer the last point with any confidence, that's a sign to spend more time in Stage 1 rather than move on.

Stage 2: Your Draft Proposal

Proposal Elements

Every draft should cover the same ground regardless of type: a clear title, a description that states the problem and the proposed change, the concrete technical payload (parameter key/value, upgrade height, recipient and amount, or validator info), and the deposit you intend to attach. See Formatting a Proposal for the exact JSON shape each type expects.

A draft that's missing any of these tends to generate a round of clarifying questions during review instead of substantive feedback, which just slows everything down.

Parameter-Change

If your draft is a parameter change, name the exact subspace and key you intend to touch and state the current value alongside the proposed one.

Cross-check the current value on a live node before publishing the draft. Announcing a target that's already stale, because the parameter changed since you last checked, undermines confidence in the rest of the proposal even if the substance is still sound:

aiozd query params subspace <subspace> <key>

A subspace/key typo is one of the most common ways a parameter-change proposal fails silently: the transaction can succeed and the proposal can even pass, while touching the wrong parameter or none at all. Testing the exact payload on testnet (see below) is the only reliable way to catch this before it costs a mainnet deposit.

Community-Spend Proposal

If your draft requests funds from the community pool, state the exact recipient address and amount, and check the pool's current balance so the ask is credibly sized against what's actually available:

aiozd query distribution community-pool

Because disbursement happens automatically the moment the proposal passes, with no further approval step, a credible draft also states who's accountable for the funded work and how the community will know it was delivered. See Community Pool Spend for the full mechanics.

Begin With a Well-Considered Draft Proposal

Don't publish the first version you write. Read it back as if you were a validator with no context: does it stand on its own, or does it assume knowledge only you have? Would someone skimming it in Telegram between other conversations come away with the right understanding, or would they need to ask you three follow-up questions first?

Tighten the language before it goes out for community review; every ambiguity you leave in is a question you'll field repeatedly instead of just once.

Engage the Community With Your Draft Proposal

Post the full draft, not just a summary, in the Telegram community and, where relevant, tag validators whose vote will matter most. Leave real time for questions and objections, and revise the draft in response rather than defending the first version reflexively.

If the same objection comes up from more than one person, that's a signal the draft needs to change, not just be explained better. Expect to go through more than one revision; a draft that survives its first public read unchanged is unusual, not the norm.

Submit Your Proposal to the Testnet

Before spending a real deposit on mainnet, submit the exact same proposal, same type, same JSON payload, on AIOZ testnet (chain-id: aioztestnet_4102-2). This is the cheapest way to catch a malformed JSON file, a wrong subspace/key pair, or a rejected message type.

Let it run through its full deposit and voting period on testnet if you can; a proposal that behaves unexpectedly once live is far easier to debug when nothing real is at stake. See Submitting a Proposal for the exact commands.

Stage 3: Your On-Chain Proposal

The Deposit Period

Once submitted on mainnet, a proposal sits in the deposit period until its total deposit reaches min_deposit (currently 1000 AIOZ) or max_deposit_period (2 days) runs out. Anyone can contribute to the deposit, not only the original proposer. Coordinating a handful of community members to cover the deposit together is common and fine, and can itself be a useful early read on how much real support the proposal has.

If the deposit period expires before min_deposit is reached, the proposal is dropped and every deposit already contributed to it is burned. It's worth lining up enough committed depositors before submitting rather than hoping the rest arrives organically.

The Voting Period

As soon as min_deposit is met, voting opens for voting_period, 2 days on AIOZ mainnet. That's still well short of Cosmos Hub's roughly two weeks, so treat the transition into the voting period as a signal to your validator contacts to cast their vote promptly, not as the start of the persuasion process; by the time voting opens, the outcome should already be largely decided by the off-chain work above.

The gov module's parameters do include a shorter, higher-bar "expedited" track (see On-Chain Proposal Process), but the exact CLI flag or subcommand to submit on that track wasn't confirmed by testing against a real node; verify it directly with a current aiozd build before relying on it.

See On-Chain Proposal Process for exactly how votes are tallied.