AIOZ Blockchain - EVM x Cosmos
Governance
Formatting a Proposal

Formatting a Proposal

Every proposal type needs its payload formatted a specific way before it can be submitted with aiozd tx gov submit-legacy-proposal. This page covers the exact JSON shape for each type; see Proposal Types for what each one is actually for, and Submitting a Proposal for the transaction commands themselves.

A malformed proposal file doesn't just fail loudly, it can fail silently by targeting the wrong field, so it's worth validating the JSON against a real schema or a local --dry-run before spending a real deposit on it. The shapes below match what AIOZ Network's aiozd actually accepts today; a chain upgrade that adopts the newer gov v1 Msg-based interface (see Submitting a Proposal) would change this.

Text

A Text proposal carries no structured payload, only a title and description, which can be passed directly as CLI flags without a JSON file:

aiozd tx gov submit-legacy-proposal \
  --title="<title>" \
  --description="<description>" \
  --type="Text" \
  --deposit="1000000000000000000000attoaioz" \
  --from=<key> \
  --chain-id=<chain_id>

Community Pool Spend

A Community Pool Spend proposal needs a JSON file specifying who receives funds and how much. There's no field for milestones, conditions, or a spending schedule; the module only understands a single recipient and a single amount, so anything more nuanced about how the funds should be used has to live in the description instead:

{
  "title": "<title>",
  "description": "<description>",
  "recipient": "<recipient_address>",
  "amount": "<amount>attoaioz",
  "deposit": "1000000000000000000000attoaioz"
}
⚠️

amount takes a single coin string ("5000000000000000000000attoaioz"), not an array of {denom, amount} objects. Confirmed by generating an unsigned transaction against a real node: passing an array here fails with json: cannot unmarshal array into Go value of type string.

aiozd tx gov submit-legacy-proposal community-pool-spend <path/to/proposal.json> \
  --from=<key> \
  --chain-id=<chain_id>

Legacy Param Change

A Parameter Change proposal needs a JSON file listing each subspace/key/value triple to change. The value field's type has to match what the target parameter expects exactly, a string where a boolean is expected (or vice versa) is a common way for a proposal to pass but fail to execute the intended change:

{
  "title": "<title>",
  "description": "<description>",
  "changes": [
    {
      "subspace": "<subspace>",
      "key": "<key>",
      "value": "<value>"
    }
  ],
  "deposit": "1000000000000000000000attoaioz"
}
aiozd tx gov submit-legacy-proposal param-change <path/to/proposal.json> \
  --from=<key> \
  --chain-id=<chain_id>

Real Example

AIOZ mainnet's Proposal 1 used exactly this shape to disable open validator self-registration:

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

See Parameter Changes for the full context behind this example.