Software Upgrade
A Software Upgrade proposal schedules a coordinated binary upgrade: a target block height (or time) at which every validator and full node is expected to switch to a new aiozd build at the same instant, so the network doesn't fork.
Real History
Software Upgrade proposals are the second most common type on AIOZ mainnet after Create-Validator, with real passed examples including the v1.6 and v1.7 network upgrades. This is a mature, actively-used mechanism, not a theoretical one.
Submitting a Software Upgrade Proposal
aiozd tx gov submit-legacy-proposal software-upgrade <name> \
--title="<title>" \
--description="<description>" \
--upgrade-height=<height> \
--deposit="1000000000000000000000attoaioz" \
--from=<key> \
--chain-id=<chain_id><name> is a unique identifier for the upgrade, referenced later by the binary directory Cosmovisor looks for. --upgrade-info can optionally point to a JSON blob with binary download links, in the format Cosmovisor (opens in a new tab) expects.
This command's structure (subcommand under submit-legacy-proposal, --upgrade-height/--upgrade-info flags) was confirmed via --help against a real node. Building and broadcasting an actual upgrade transaction wasn't tested, since a real upgrade shouldn't be rehearsed against mainnet.
Canceling a Scheduled Upgrade
A scheduled upgrade can be called off with a follow-up proposal before it executes:
aiozd tx gov submit-legacy-proposal cancel-software-upgrade \
--title="<title>" \
--description="<description>" \
--deposit="1000000000000000000000attoaioz" \
--from=<key> \
--chain-id=<chain_id>After It Passes
A passed Software Upgrade proposal doesn't update anyone's node automatically. Node operators still need to swap in the new binary at the target height, either manually or via Cosmovisor. See Software Upgrade for that operational side; this page only covers proposing the upgrade through governance, not executing it once scheduled.