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.