Client Engineering – Q3 2026 Funding Proposal

[isaac9905]

Client Engineering – Q3 2026 Funding Proposal

Summary

This proposal seeks community approval to fund the Overclock Labs client engineering team for the Client and Console work delivered during Q3 2026. Building on the Console redesign funded in Proposal 332, this work spans automatic escrow funding for managed wallets, server-side data persistence and secrets, the continued Console redesign, and Console support for ARM64 and InfiniBand deployments.

The AEPs and initiatives covered by this proposal are:

• AEP-91 – Escrow Abstraction + Auto Funding: automatic escrow funding and top-ups for managed-wallet deployments, a single account balance, and threshold-based card reloads.
• AEP-92 – Data Persistence + Secrets: moving per-user Console data into Console's database and adding KMS-backed secrets referenced by name in the SDL.
• Console Redesign Continuation (AEP Pending): extending the redesign beyond the deploy flow to the rest of Console, launching publicly at the Cyberdefense Hackathon on October 9.
• ARM64 Support, Console Implementation: architecture selection in Console and Console Air.
• InfiniBand / RoCE Interconnect, Console Implementation: interconnect support in Console and the TypeScript chain-sdk.

Motivation

Two of the most common ways a Console deployment fails have nothing to do with the workload itself. A user picks an escrow deposit, forgets to top it up, and the deployment closes even though the account still has credits. Or a user clears their browser or switches machines and loses the saved deployments and templates they relied on. AEP-91 and AEP-92 remove both failure modes. Console now funds deployments automatically and keeps them topped up to a target runway, and per-user data and secrets are stored server-side, with secrets encrypted and kept out of the SDL.

The Q2 redesign rebuilt the deploy flow. The rest of Console, including the deployments list, deployment detail, providers, templates, billing and settings pages, still used the previous design, so users moved between two different experiences. The Q3 redesign work brings those pages onto the new design so Console feels like one product.

ARM64 support lets users target the new class of ARM hardware that providers can now advertise, and interconnect support (AEP-95) lets users set up RDMA-connected multi-node GPU deployments for training and fine-tuning directly from Console.

Total Request

For the Q3 2026 Client Engineering Proposal, Overclock Labs is requesting $222,186 from the Community Pool for work directly attributable to the client AEPs for this period, alongside a 54.3% AKT volatility buffer.

	Request from CP
Engineering hours	775.57
Engineering rate per hour	$180.75
Engineering total cost	$140,182
Support hours	48.65
Support rate per hour	$78.39
Support total cost	$3,814
Labor Subtotal	$143,996
AKT Volatility Buffer (54.3%)*	$78,190
Total Request	$222,186

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

Budget Breakdown

	Hours	Cost
Console Redesign – Continued	567.81	$97,953.40
As a percentage of total labor budget	68.89%	68.03%
Escrow Abstraction + Auto Funding (AEP-91)	124.13	$23,606.19
As a percentage of total labor budget	15.06%	16.39%
Data Persistence + Secrets (AEP-92)	102.51	$16,774.00
As a percentage of total labor budget	12.44%	11.65%
ARM64 Support – Console Implementation	13.00	$2,472.27
As a percentage of total labor budget	1.58%	1.72%
InfiniBand / RoCE Interconnect (AEP-95) – Console Implementation	16.77	$3,190.03
As a percentage of total labor budget	2.03%	2.22%
Total	824.22	$143,995.89

AEP Summary

AEP-91: Escrow Abstraction + Auto Funding

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

Problem Addressed: Managed-wallet users had to choose an escrow deposit for each deployment and top it up by hand, and deployments could close when escrow ran dry even though the account still had credits.

Key Features Introduced:

• Automatic escrow funding when a lease starts and when credits land, with each deployment kept topped up to a target runway.
• A single account balance in place of per-deployment escrow.
• Threshold-based card reloads with safeguards against repeat charges.
• Optional runtime limits for deployments that should stop at a set time.

AEP-92: Data Persistence + Secrets

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

Problem Addressed: Saved deployments, templates, favorites and settings lived in browser storage, so they didn't follow users across devices and were lost when storage was cleared. Sensitive values like API keys had to be pasted into the SDL as plain text.

Key Features Introduced:

• Per-user Console data and deployment definitions moved into Console's database so they persist across devices and sessions.
• Encrypted secrets storage under a KMS-backed key system, with per-user data keys and key rotation.
• Secrets referenced in the SDL by name rather than pasted in as plain text, and carried forward automatically on redeploy.
• A variables and secrets editor on the Console configure screen.

Console Redesign (continued)

Related Proposal: Q2 2026 Client Engineering (Proposal 332)

Problem Addressed: The Q2 redesign rebuilt Console's deploy flow, but the rest of Console still used the previous design, leaving users moving between two inconsistent experiences.

Key Features Introduced:

• Post-release refinements to the Q2 deploy flow and onboarding based on early user feedback.
• Redesigned deployments list and deployment detail pages.
• Redesigned providers, templates and deployment-type selection pages, with SDL upload.
• Redesigned billing, usage, alerts, API keys and profile settings, plus in-app feedback.

The redesigned Console will launch publicly at the Cyberdefense Hackathon during SF Tech Week on October 9, 2026, which Akash is sponsoring.

ARM64 Support – Console Implementation

Problem Addressed: With providers now able to report CPU architecture and the bid engine matching on it, users needed a way to target ARM64 providers from Console.

Key Features Introduced:

• Architecture selection in Console and Console Air when configuring a deployment, matching the provider-side support merged in provider #433.

InfiniBand / RoCE Interconnect – Console Implementation

Problem Addressed: Multi-node GPU deployments over an RDMA fabric require an interconnect attribute in the SDL, which users would otherwise have to add by hand.

Key Features Introduced:

• Support for the InfiniBand/RoCE interconnect attribute in Console and the TypeScript chain-sdk, so RDMA-connected multi-node GPU deployments can be set up through Console. See the GPU interconnect documentation.

Conclusion

Q3's client work takes the friction out of keeping a workload running once it's deployed. Automatic funding keeps deployments alive as long as the account has credits, server-side persistence and secrets make Console dependable across devices and safe for production credentials, the continued redesign brings the rest of Console in line with the new deploy flow, and the ARM64 and interconnect work puts this quarter's new hardware capabilities in front of users. Together these support user retention and open Console to new classes of supply and workload.

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.

Overclock Labs will coordinate with the Decentralized Cloud Foundation (DCF) on the timing and execution of liquidations, so that conversions of these funds are aligned with other market activity across the ecosystem and are not working against one another.

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.