8-vaxildan Network Upgrade

Original Proposal Text

# FUND MainNet Network Upgrade ## 8-vaxildan The network will be upgraded to the latest `und` application, **v1.13.4**, which updates the Cosmos SDK to ([v0.54.4](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.54.4)), IBC to ([v11.2.0](https://github.com/cosmos/ibc-go/releases/tag/v11.2.0)) and CometBFT to ([v0.39.4](https://github.com/cometbft/cometbft/releases/tag/v0.39.4)). Cosmos SDK v0.54.4 is an upstream **security release** and is **state-breaking**, and therefore requires a coordinated network upgrade. This is a scheduled upgrade that will occur automatically via the `upgrade` module at the height specified below: **Upgrade Name:** 8-vaxildan **Binary:** und v1.13.4 **Upgrade Height:** 24172000 **Predicted Upgrade Time:** Wed 28 Oct 2026, 12:00:00 UTC The predicted date/time for this block is an **approximation**. The actual time may vary by 1 - 2 hours either way due to fluctuating block times. ### Summary of changes In addition to the dependency updates above, `8-vaxildan` includes: - **Payment Streams are now multi-denomination.** A sender and receiver pair may run several concurrent streams in different denominations, each with its own deposit, flow rate and claim schedule. Existing streams are migrated automatically and require no action from users. - **Payment Streams have moved into a standalone module**, [x-stream](https://github.com/unification-com/x-stream) (`v0.1.3`), consumed by `und` as an external dependency. This is a wire-preserving change - existing streams are unaffected. - **BEACON timestamps gain an optional `metadata` descriptor** (256-byte cap) and a new `BeaconTimestampsByHash` query, allowing a stamped hash to be looked up directly. The hash index is **forward-only**: existing BEACON records are not rewritten or backfilled, and remain exactly as they are. - **The `x/group` and `x/circuit` modules are removed** (both verified empty on TestNet and MainNet). - **CLI commands have migrated to autocli.** Backwards-compatible flag aliases and shims are in place for the custom module commands, but node operators and tooling authors should review the release notes. v1.13.4 also restores automatic fee calculation for `und tx beacon` and `und tx wrkchain`. ### Tested on TestNet `8-vaxildan` was applied on TestNet on 11 August 2026 at block 25,638,900. Consensus resumed 19 seconds after the upgrade halt, with the state migrations themselves taking around 2 seconds. TestNet has been running v1.13.4 since 20 August 2026. The upgrade was also rehearsed end-to-end on the [upgrade simulator](https://github.com/unification-com/mainchain-upgrade-simulator) against a multi-node network under continuous load, including a live IBC counterparty chain. ### What to expect at the upgrade height On MainNet, the time until blocks resume will depend mainly on how quickly validators restart their nodes and reconnect to their peers, rather than on the state migration. Blocks resume once validators holding more than two thirds of the voting power are back online, so **please have v1.13.4 staged in advance and be available around the upgrade time**. Cosmovisor's default pre-upgrade backup copies the whole `data` directory, which on MainNet can take tens of minutes. Validators who keep their own backups may wish to set `UNSAFE_SKIP_BACKUP=true` so that their node rejoins quickly. ### Configure the binaries and `cosmovisor` directories for the upgrade The recommended method for handling this and future upgrades is via Cosmovisor. In order to prepare Cosmovisor for the upgrade, node operators will need to download the specified binary to the appropriate location. A guide to setting up the required binaries and directory structure for the `8-vaxildan` upgrade can be found here: https://docs.unification.io/mainchain/migrations/8-vaxildan_upgrade The above should be implemented on **all** nodes (Validators, Sentries, RPCs, Seeds etc.) before block **24172000**. Manual upgrade is possible, but may incur additional time and effort for the node operator. ## Voting Context The following items summarise the voting options and what they mean for this proposal: **YES** - You agree that Unification network should be updated with this release. **NO** - You disagree that the Unification network should be updated with this release. **NO WITH VETO** - A 'NoWithVeto' vote indicates a proposal is, for example, (1) deemed to be spam, i.e., irrelevant to Unification, (2) deemed to be harmful to the Unification network and/or community. If the number of 'NoWithVeto' votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. **ABSTAIN** - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal. --- Full proposal text also archived at https://ipfs.io/ipfs/QmWGBLJe9RXpWeLCJzWJFvkviAYnYaSbTemSam2LAZj4nc More details: ipfs://QmZLEyPCZUug48rgcPqpCyNXEhaZ5NsvsmEjPidb6DxET2