Client Engineering – Q2 2026 Funding Proposal

[isaac9905]

Client Engineering – Q2 2026 Funding Proposal

Summary

As the development of Akash Network accelerates with the continued support of Community Pool resources, the Akash Core Team publishes AEP funding requests in quarterly batches encompassing features shipped during each period.

In Q2, the client engineering team's focus was the Akash Console redesign — an overhaul of the primary interface for deploying workloads on the network. The redesign exists to reduce the friction that has historically stood between a new user and a running workload: it replaces the legacy multi-step deployment wizard with a single stateful configure surface, separates the managed and crypto-native experiences so each can be simpler, and makes the network's newest protocol capabilities — confidential compute and resource reclamation — usable directly from Console rather than only on-chain. Together these changes lower the barrier to entry for the tenant base Akash is now attracting, from individual developers to enterprise teams running production workloads.

The redesign was delivered as four completed items:

• AEP-84 — Console Redesign & Console Air: the new deployment surface and the split of the crypto-native experience into a standalone Console Air application.
• AEP-67 — Console Bid Screening: pre-screening providers against a deployment's requirements so users only see providers that would actually bid.
• AEP-83 — Confidential Compute Console Support: surfacing TEE configuration and letting tenants download and verify attestation evidence without leaving Console.
• AEP-82 — Provider Reclamation UI: provider-side controls for configuring resource reclamation and reclamation-aware marketplace behavior for tenants.

Motivation

Akash Console is the primary interface for deploying workloads on the network, so its usability directly shapes adoption. The Q2 redesign overhauls the managed Console experience and breaks the crypto-native experience off into a new Console Air application (AEP-84). The centerpiece is a single stateful configure surface at /new-deployment/configure, built around a three-pane model — Deployment, Configuration, and Compute Marketplace — that owns the full deploy lifecycle end-to-end: create deployment, request quotes, select provider, sign lease, and transition to deployment details.

The remaining three items were built into that redesigned surface to expose this period's core protocol work to users. Bid screening (AEP-67) tells users why they receive zero bids instead of letting deployments silently fail, backed by a new provider-inventory service that streams live cluster state from every active provider. Confidential-compute support (AEP-83) surfaces declared TEE configuration and lets tenants download and validate attestation evidence against hardware vendors. Reclamation controls (AEP-82) give providers a UI to configure reclamation and make its effects visible in the marketplace. Each is a distinct deliverable, but all three reach users through the redesigned Console — which is why the redesign was the throughline of the quarter's client work.

Total Request

For the Q2 2026 Client Engineering Proposal, Overclock Labs is requesting $395,812 from the Community Pool for work directly attributable to the client AEPs for this period, alongside a 44.7% AKT volatility buffer.

	Request from CP
Engineering hours	1,586.38
Engineering rate per hour	$169.25
Engineering total cost	$268,495
Support hours	65.14
Support rate per hour	$77.45
Support total cost	$5,045
Labor Subtotal	$273,540
AKT Volatility Buffer (44.7%)*	$122,272
Total Request	$395,812

*AKT Volatility Buffer — A 44.7% buffer is applied to this request to ensure adequate coverage during an adequate liquidation based on the past 180 days of AKT price fluctuations (applied as of 7/1/26). Any unused buffer during liquidation will be returned.

Budget Breakdown

	Hours	Cost
Resource Reclamation (AEP-82) - Console Implementation	85.71	$14,342.10
As a percentage of total labor budget	5.19%	5.24%
Console Redesign & Self Custody (AEP-84)	815.14	$139,481
As a percentage of total labor budget	49.36%	50.99%
Confidential Compute via Kata Containers (AEP-83) - Console Development	53.71	$9,959.24
As a percentage of total labor budget	3.25%	3.64%
Console Bid Screening (AEP-67)	696.96	$109,758.05
As a percentage of total labor budget	42.20%	40.12%

AEP Summary

AEP-84: Console Redesign / Console Air Implementation

Specification: https://akash.network/roadmap/aep-84/

Problem Addressed: The multi-step deployment wizard added friction to the most important flow in Console, and lingering self-custody (Keplr / cosmos-kit) code paths increased complexity and maintenance burden while fragmenting the authentication experience.

Key Features Introduced:

• Replaces the legacy multi-step deployment wizard with a single stateful configure surface at /new-deployment/configure, built around a three-pane model: Deployment, Configuration, and Compute Marketplace. That surface owns the full lifecycle end-to-end: create deployment, request quotes, select provider, sign lease, and transition to deployment details.
• Adds a server-driven onboarding and account-state model with accountStage (onboarding, trial, trialLegacy, regular) plus a separate verified flag. This powers forced /onboarding routing, gated access until first successful deploy, verification-triggered credit upgrades, and deterministic recovery of in-flight deployments after refresh or deep-link entry.
• Provides the unified quote-selection-deploy lifecycle and configuration framework that hosts this period's feature work — bid screening (AEP-67), reclamation-window controls (AEP-82), and Confidential Compute filtering (AEP-83) — via URL-driven intent parameters (templateId, sdl-strategy, bid-strategy), deploy-progress overlay reuse, and auto-vs-manual provider selection. The features themselves are scoped and costed under their respective AEPs below.
• Enforces managed-wallet-only authentication across all routes and removes self-custody (Keplr / cosmos-kit) code paths from Console, introducing the standalone Console Air application for self-host / self-custody users.

AEP-67: Console Bid Screening

Specification: https://akash.network/roadmap/aep-67/

Problem Addressed: Console users often see plenty of "available" GPUs on the pricing/providers page, proceed to deploy, and then receive zero bids — with no indication of why. This makes the service look broken and causes users to abandon deployment rather than adjust their SDL.

Key Features Introduced:

• Bid screening against a deployment's requirements before the on-chain order is created, so users only see providers that would actually bid — surfaced inline in the redesigned deployment configuration workflow.
• Clear rejection reasons when zero providers match — flags the specific excluding dimension (aggregate capacity, per-node GPU count, GPU model, CPU/memory headroom, storage class, attributes, or price).
• A new apps/provider-inventory backend service that streams live cluster state from every active provider via long-lived gRPC connections into a continuously maintained inventory snapshot.

AEP-83: Confidential Compute Support

Problem Addressed: Tenants running confidential-compute workloads needed a way to see the declared TEE configuration and to obtain and verify attestation evidence without leaving Console.

Key Features Introduced:

• Declared Confidential Compute configuration surfaced on the deployment view.
• Download of attestation evidence for a confidential-compute deployment.
• Validation of attestation evidence against hardware vendors.

AEP-82: Provider Reclamation UI

Problem Addressed: Resource Reclamation is implemented at the protocol layer, but providers need a UI to configure reclamation behavior and tenants benefit from reclamation-aware marketplace surfacing.

Key Features Introduced:

• Provider Console UI/UX for configuring resource reclamation.
• Minimum reclamation-window control and reclamation-aware marketplace behavior in Console.

Conclusion

The Console Redesign (AEP-84) is the most significant client-facing change in this proposal: a streamlined, managed-wallet-native deploy experience that lowers the barrier to running workloads on Akash. Combined with the Console features for confidential compute and resource reclamation, this work turns the network's protocol capabilities into features tenants and providers can actually use — reducing friction, building confidence in Akash as a production-ready platform, and supporting both user adoption and provider growth.

Limited Market Impact & Transparent Reporting

Overclock Labs will custody the requested funds in a new, distinct wallet so that funds from any other source are not commingled.

All funds will be liquidated and managed to minimize market impact. These funds will be handled with the same care and attention as all previous Community Funding Proposals, with liquidations done in a fashion that will not adversely affect the market. In practice, the effort of this liquidation will add depth to the AKT market for buyers looking to enter.

In some cases, Overclock Labs will use structured market-making (MM) activity to manage funds responsibly. Conversions will take place gradually over defined trading windows rather than through large sell transactions. Spreading activity over these longer windows helps ensure that each trade reduces the likelihood of noticeable price movements and helps maintain a stable market for all participants. This measured approach allows Overclock Labs to meet operational needs while minimizing market impact and supporting steady liquidity within the AKT ecosystem.