{"proposal":{"id":"328","messages":[{"@type":"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade","authority":"akash10d07y265gmmuvt4z0w9aw880jnsr700jhe7z0f","plan":{"name":"v2.1.0","time":"0001-01-01T00:00:00Z","height":"27230465","info":"https://raw.githubusercontent.com/akash-network/net/main/mainnet/upgrades/v2.1.0/info.json","upgraded_client_state":null}}],"status":"PROPOSAL_STATUS_PASSED","final_tally_result":{"yes_count":"56883189657902","abstain_count":"170000","no_count":"0","no_with_veto_count":"0"},"submit_time":"2026-06-03T15:59:14.821274939Z","deposit_end_time":"2026-06-17T15:59:14.821274939Z","total_deposit":[{"denom":"uakt","amount":"1000000000"}],"voting_start_time":"2026-06-03T16:36:25.314757532Z","voting_end_time":"2026-06-10T16:36:25.314757532Z","metadata":"","title":"Akash Mainnet 18 Upgrade","summary":"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**.\n\n**Note:** Block times have high variance. Please monitor the chain for more precise timing estimates.\n\n## Upgrade Features\n\nBy voting **YES** on this proposal, you approve the following changes:\n\n### 1. Oracle v2\n\nOracle 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:\n\n- **Wall-clock time model** — Staleness, TWAP, and queries are driven by timestamps and durations rather than block heights, removing dependence on block cadence.\n- **Epoch-based pruning** — Bounds state growth over time.\n- **Explicit source identity management** — Price sources are tracked via auto-incrementing numeric IDs.\n- **Transient store** — Provides per-block sequence disambiguation.\n- **Sortable timestamp key encoding** — Lexicographically-sortable keys enable efficient range queries.\n- **Future-time-drift protection** — Rejects submissions timestamped improperly far in the future.\n- **Flattened message/event schema** — Separates price values from timestamps.\n- **Time-range query API** — Upgrades the query interface from single-height lookups to time-range filters.\n- **Modern collections-based state** — Adopts `cosmossdk.io/collections` for typed, indexed state management, replacing raw KV store operations.\n\n**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.\n\n### 2. Resource Reclamation\n\nIntroduces 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.\n\nToday 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:\n\n- **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.\n- **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.\n- **Negotiated window** — The reclamation window is a wall-clock duration agreed at bid time and stored on the lease at creation.\n- **Reclamation initiation** — A provider initiates reclamation via the new `MsgLeaseStartReclaim`, transitioning the lease from `Active` to the new `Reclaiming` state and setting a deadline.\n- **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.\n- **Governance bounds** — New market module parameters enforce minimum and maximum reclamation window durations (defaults: `min` 1h, `max` 720h / 30 days).\n\nThis 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.\n\n### 3. Market Order Close Event Fix\n\nResolves 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.\n\nWhen 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.\n\nThe 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.\n\nThis 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.\n\n### Binary Installation\n\n#### Option 1: Precompiled Binaries (Recommended)\n\nThis upgrade links an `info.json` file that references the correct release with pre-built binaries.\n\n#### Option 2: Self-Compiled Binaries\n\n**Requirements:**\n\nEnsure the following dependencies are installed:\n- `direnv`\n- `golang \u003e= 1.26`\n- `docker`\n- `make`\n- `git`\n- `jq`\n- `unzip`\n- `wget`\n- `curl`\n- `npm`\n- `readlink`\n- `lz4`\n\n**Build Instructions:**\n\n```bash\n# Clone the repository\ngit clone https://github.com/akash-network/node.git\n# Navigate to the directory\ncd node\n\n# Checkout the release tag\ngit checkout v2.1.0\n\n# Build the binary\nmake release\n```\n\nBinaries will be located in `.cache/goreleaser/main`.\nSelect the directory matching your OS and architecture.\n\n### Hardware Requirements\n\nThis 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:\n\n- **At least 32GB of RAM**\n- **Swap enabled**\n\nAs with any state-breaking upgrade, validators are strongly encouraged to snapshot their node prior to the upgrade height.\n\n## Upgrade Process\n\n### Using Cosmovisor (Recommended)\n\nValidators 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).\n\n### Manual Upgrade\n\nIf not using Cosmovisor:\n1. Wait for your node to halt at the upgrade height\n2. Install the new binary\n3. Restart your node\n\n---\n\n## Upgrade Timing Details\n- **Target Block Height:** 27230465\n\n\u003e Block times vary significantly. Monitor the countdown on [Mintscan](https://www.mintscan.io/akash/block/27230465) for accurate timing.\n\nDuring the upgrade, there will be no on-chain activity on the network.\n\n### Emergency Coordination\n\nIn the event of issues during the upgrade, please coordinate via the **validators channel in Discord** to reach emergency consensus and mitigate problems quickly.\n\n---\n\n## Additional Resources\n\n- [Akash Network GitHub](https://github.com/akash-network)\n- [Block Explorer](https://mintscan.io/akash/)\n","proposer":"akash1xrvksdjxnhk5rkz420k5km6cl7f0xs48eq32rc","expedited":false,"failed_reason":""}}