Akash Mainnet 18 Upgrade

Original Proposal Text

This proposal upgrades the Akash Network to version **v2.1.0** at block height [27230465](https://www.mintscan.io/akash/block/27230465), estimated to occur on **June 11th, 2026 at ~14:00 UTC**. **Note:** Block times have high variance. Please monitor the chain for more precise timing estimates. ## Upgrade Features By voting **YES** on this proposal, you approve the following changes: ### 1. Oracle v2 Oracle v2 is a fundamental architectural redesign of the `x/oracle` module introduced in the prior mainnet upgrade. The core shift replaces block-height-based time referencing with wall-clock timestamps and durations, making staleness detection, TWAP computation, and price querying independent of block production cadence. Key additions: - **Wall-clock time model** — Staleness, TWAP, and queries are driven by timestamps and durations rather than block heights, removing dependence on block cadence. - **Epoch-based pruning** — Bounds state growth over time. - **Explicit source identity management** — Price sources are tracked via auto-incrementing numeric IDs. - **Transient store** — Provides per-block sequence disambiguation. - **Sortable timestamp key encoding** — Lexicographically-sortable keys enable efficient range queries. - **Future-time-drift protection** — Rejects submissions timestamped improperly far in the future. - **Flattened message/event schema** — Separates price values from timestamps. - **Time-range query API** — Upgrades the query interface from single-height lookups to time-range filters. - **Modern collections-based state** — Adopts `cosmossdk.io/collections` for typed, indexed state management, replacing raw KV store operations. **Migration note:** The v1-to-v2 migration performs a complete state wipe followed by re-initialization with a freshly deployed Pyth contract. The fundamental incompatibility between block-height-keyed and timestamp-keyed storage schemas precludes in-place data conversion. Price history from v1 is not carried forward; the feed re-initializes from fresh submissions after the upgrade. ### 2. Resource Reclamation Introduces implementation of [AEP-82](https://github.com/akash-network/AEP/tree/main/spec/aep-82) as a marketplace extension that provides a negotiated grace period before provider-initiated lease termination. Today a provider that needs to terminate a lease can only close it immediately or wait for the tenant to act. Immediate closure is disruptive — tenant workloads are terminated without warning, risking data loss and downtime — and there is no on-chain mechanism for a provider to give advance notice. This blocks common provider scenarios such as planned maintenance, capacity decommissioning, and resource rebalancing. Resource Reclamation adds a wall-clock grace period that is negotiated between tenant and provider at bid time. Key capabilities: - **Tenant opt-in** — A tenant may specify a minimum reclamation window in `MsgCreateDeployment`. Providers that do not support reclamation must not bid on such deployments. - **Provider opt-in** — A provider may offer a reclamation window in their bid, even for deployments that do not require it. When required, the offered window must meet or exceed the tenant's minimum. - **Negotiated window** — The reclamation window is a wall-clock duration agreed at bid time and stored on the lease at creation. - **Reclamation initiation** — A provider initiates reclamation via the new `MsgLeaseStartReclaim`, transitioning the lease from `Active` to the new `Reclaiming` state and setting a deadline. - **Window enforcement** — During the window the provider cannot close the lease; the tenant can close at any time. Payments continue at the full lease rate. After the window elapses, either party may close. - **Governance bounds** — New market module parameters enforce minimum and maximum reclamation window durations (defaults: `min` 1h, `max` 720h / 30 days). This change adds a new `LeaseReclaiming` state (value `4`) to the lease state machine, a new `MsgLeaseStartReclaim` market message, an `EventLeaseReclaimStarted` event, and new reclamation fields on the deployment, order, bid, and lease records. ### 3. Market Order Close Event Fix Resolves a marketplace event bug ([support#438](https://github.com/akash-network/support/issues/438)) in which `EventOrderClosed` was not emitted when a deployment or group was closed while its order was still in the `OrderOpen` state. When a deployment is closed before any lease is created, the order remains `OrderOpen` (bids may be open, since no `MsgCreateLease` has run). In that path, `OnGroupClosed` previously iterated only `OrderActive` orders, so it never called `OnOrderClosed` for the still-open order — and `OnOrderClosed` is the only place `akash.market.v1.EventOrderClosed` is emitted. The deployment module still correctly emitted `EventDeploymentClosed` and `EventGroupClosed`, but the corresponding market-level order-closed signal was missing. The practical impact was on downstream consumers that listen only for `EventOrderClosed` — most notably the provider `bidengine` — which never received a market-level "order closed" signal for this path, leaving open bids and orphaned bid state. This upgrade corrects `OnGroupClosed` in `x/market` to include orders in the `OrderOpen` state, ensuring `OnOrderClosed` runs and `EventOrderClosed` is emitted (and open bids are closed) when a deployment or group is closed before any lease exists. ### Binary Installation #### Option 1: Precompiled Binaries (Recommended) This upgrade links an `info.json` file that references the correct release with pre-built binaries. #### Option 2: Self-Compiled Binaries **Requirements:** Ensure the following dependencies are installed: - `direnv` - `golang >= 1.26` - `docker` - `make` - `git` - `jq` - `unzip` - `wget` - `curl` - `npm` - `readlink` - `lz4` **Build Instructions:** ```bash # Clone the repository git clone https://github.com/akash-network/node.git # Navigate to the directory cd node # Checkout the release tag git checkout v2.1.0 # Build the binary make release ``` Binaries will be located in `.cache/goreleaser/main`. Select the directory matching your OS and architecture. ### Hardware Requirements This upgrade adds the resource reclamation marketplace extension and performs a state-breaking redesign of the `x/oracle` module, including an oracle state wipe and redeployment of the Pyth contract. It is recommended that all validators meet the following: - **At least 32GB of RAM** - **Swap enabled** As with any state-breaking upgrade, validators are strongly encouraged to snapshot their node prior to the upgrade height. ## Upgrade Process ### Using Cosmovisor (Recommended) Validators and RPCs supervised by Cosmovisor with `DAEMON_ALLOW_DOWNLOAD_BINARIES=true` will automatically download upgrade binaries from the [upgrade info file](https://raw.githubusercontent.com/akash-network/net/main/mainnet/upgrades/v2.1.0/info.json). ### Manual Upgrade If not using Cosmovisor: 1. Wait for your node to halt at the upgrade height 2. Install the new binary 3. Restart your node --- ## Upgrade Timing Details - **Target Block Height:** 27230465 > Block times vary significantly. Monitor the countdown on [Mintscan](https://www.mintscan.io/akash/block/27230465) for accurate timing. During the upgrade, there will be no on-chain activity on the network. ### Emergency Coordination In the event of issues during the upgrade, please coordinate via the **validators channel in Discord** to reach emergency consensus and mitigate problems quickly. --- ## Additional Resources - [Akash Network GitHub](https://github.com/akash-network) - [Block Explorer](https://mintscan.io/akash/)