Prop 328: Akash Mainnet 18 Upgrade

This proposal upgrades the Akash Network to version v2.1.0 at block height 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 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) 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:

# 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.

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 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
• Block Explorer