Core Engineering – Q3 2026 Funding Proposal

[isaac9905]

Core Engineering – Q3 2026 Funding Proposal

Summary

This proposal seeks community approval to fund the Overclock Labs core team for the protocol and provider-level engineering delivered during Q3 2026. Building on the Q2 work funded in Proposal 333, this work spans the Pyth price feed migration and resilience work behind BME, a unified Akash CLI, ARM64 provider support, the mainnet release of confidential compute and InfiniBand interconnect, and a single provider configuration file.

The AEPs and initiatives covered by this proposal are:

• AEP-88 – Pyth Router-Based Price Feed Contracts: migrating Akash's AKT price feed to Pyth's router-based system before the guardian-based feed is retired.
• AEP-89 – Unified Akash Command-Line Interface: making akt the single command-line tool for Akash users.
• ARM64 Support: CPU architecture as a provider-reported attribute that tenants can request.
• Confidential Compute via Kata Containers (AEP-83) – Mainnet Release: taking TEE support from development to a live mainnet release.
• InfiniBand / RoCE Interconnect – Mainnet Release: taking multi-node GPU interconnect support from development to a live mainnet release.
• Price Feed Resilience: continuing the Pyth hardening work so the price feed layers behind BME are sustainable, including evaluating and designing a secondary AKT/USD price source.
• Provider Configuration (non-AEP): a single configuration file for provider operators.

Motivation

Akash's supply has been limited by assumptions built into the protocol. Every machine was assumed to be amd64, so providers with ARM hardware had no way to advertise it, and an amd64 container placed on an ARM node would fail after the tenant had already started paying for the lease. ARM64 support removes that limit and makes room for ARM servers and Apple Silicon. Confidential compute and InfiniBand interconnect support, whose core development was funded in Q2, were released to mainnet this quarter, giving tenants hardware-isolated workloads and multi-node GPU clusters for distributed training and fine-tuning.

The Pyth migration (AEP-88) is protective work. The on-chain oracle and Burn Mint Equilibrium both depend on an accurate AKT price, and the guardian-based Pyth feed Akash relies on is being retired upstream. The migration ran the old and new sources side by side before cutover so the price feed never went dark. The price feed resilience work is a direct continuation of that hardening, aimed at making the price feed layers behind BME sustainable rather than dependent on a single provider.

The CLI (AEP-89) and provider configuration work address the day-to-day experience of the people building on and supplying the network. Commands spread across separate binaries could look and behave differently depending on the tool, and provider settings split between CLI flags and environment variables made misconfiguration easy. Consolidating both reduces support load, simplifies documentation and automation, and makes onboarding new providers easier.

Total Request

For the Q3 2026 Core Engineering Proposal, Overclock Labs is requesting $205,916 from the Community Pool for work directly attributable to the core AEPs for this period, alongside a 54.3% AKT volatility buffer.

	Request from CP
Engineering hours	726.71
Engineering rate per hour	$176.90
Engineering total cost	$128,553
Support hours	33.55
Support rate per hour	$146.01
Support total cost	$4,898
Labor Subtotal	$133,452
AKT Volatility Buffer (54.3%)*	$72,464
Total Request	$205,916

*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
Pyth Router-Based Price Feed Contracts (AEP-88)	209.12	$41,417.74
As a percentage of total labor budget	27.51%	31.04%
Unified Akash Command-Line Interface (AEP-89)	162.71	$28,298.33
As a percentage of total labor budget	21.40%	21.20%
ARM64 Support	80.34	$16,178.81
As a percentage of total labor budget	10.57%	12.12%
Confidential Compute (AEP-83) – Mainnet Release	130.56	$16,280.82
As a percentage of total labor budget	17.17%	12.20%
InfiniBand / RoCE Interconnect – Mainnet Release	38.58	$7,475.25
As a percentage of total labor budget	5.07%	5.60%
Price Feed Resilience	86.11	$17,649.74
As a percentage of total labor budget	11.33%	13.23%
Provider Configuration (non-AEP)	52.84	$6,151.07
As a percentage of total labor budget	6.95%	4.61%
Total	760.26	$133,451.76

AEP Summary

AEP-88: Pyth Router-Based Price Feed Contracts

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

Problem Addressed: The on-chain oracle and Burn Mint Equilibrium depend on an accurate AKT price, and the guardian-based Pyth feed Akash relies on is being retired upstream.

Key Features Introduced:

• Two new smart contracts, pyth-vaa and pyth-pro, moving Akash's AKT price feed to Pyth's router-based system.
• Hermes price relayer updated for Pyth Pro authentication (hermes #17), with configurable gas and update settings.
• Old and new price sources ran side by side before cutover so the feed never went dark.

The contracts were uploaded, instantiated and registered as the oracle price source through governance proposals 335, 336, 337, 338 and 339 (July 29 – August 4), followed by a router set rotation in proposal 340.

AEP-89: Unified Akash Command-Line Interface

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

Problem Addressed: User-facing commands were spread across separate binaries (the node daemon, provider-services and others), so the same action could look and behave differently depending on the tool.

Key Features Introduced:

• Every user-facing command moved into a single akt CLI with consistent output.
• User tooling separated from daemon and library code.
• Less credential-handling code shipped with long-running services.

The akt CLI has shipped through the 0.1.x stable releases, with 1.0 in release candidate.

ARM64 Support

Problem Addressed: Akash assumed every machine was amd64. Providers with ARM hardware had no way to advertise it, and an amd64 container landing on an ARM node would fail after the tenant had already started paying for the lease.

Key Features Introduced:

• A new arch field in the SDL so tenants can request a CPU architecture.
• Automatic detection of each node's architecture on the provider side.
• Bid engine only bids when the requested and available architectures match.
• SDLs without an architecture default to amd64 so existing deployments are unaffected.

ARM64 support was merged in provider #433, shipped in provider v0.16.4 and was rolled out to community providers on September 17.

Confidential Compute via Kata Containers (AEP-83) – Mainnet Release

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

Problem Addressed: Core development of confidential compute was funded in the Q2 Core Engineering proposal. The remaining work was taking it to a production mainnet release that tenants could actually use.

Key Features Introduced:

• Confidential compute released in provider v0.16.0 (July 27) and announced live on July 28.
• A TEE-capable mainnet provider sourced and stood up, with production provider setup documentation and a confidential compute example deployment.
• Final end-to-end testing on a fresh mainnet host, including the Console flow.

InfiniBand / RoCE Interconnect – Mainnet Release

Problem Addressed: Core development of GPU interconnect support was funded in the Q2 Core Engineering proposal. The remaining work was preparing it for and completing its mainnet release.

Key Features Introduced:

• Multi-group end-to-end testing, Helm chart packaging and a final documentation review.
• Operator runbook, provider configuration example and reference SDLs for single and multi-group deployments, with GPU interconnect documentation on the Akash website.
• Released in provider v0.16.0 (July 27).

Price Feed Resilience

Related Specification: https://akash.network/roadmap/aep-81/

Problem Addressed: BME depends on a single upstream price source. A recent Wormhole guardian-set rotation disrupted the feed and showed the risk of relying on one provider.

Key Features Introduced:

• Evaluation and cost analysis of exchange APIs (CoinGecko, Coinbase, Kraken) as fallback price sources.
• Design of a price aggregation and validation layer.
• Scoping of a secondary on-chain price feed with an external oracle provider.

Why it is included: This work was tied directly to the continuation of the Pyth hardening funded in this proposal. Migrating to the new Pyth contracts addressed the immediate retirement of the old feed, and this work carries that effort forward so that the price feed layers BME depends on are sustainable over the long term. The hours requested reflect intentional engineering time dedicated to this work, not incidental support, and for that reason it is requested alongside AEP-88 rather than deferred to a later proposal.

Provider Configuration

Specification: N/A (non-AEP maintenance item)

Problem Addressed: Provider setup was split between CLI flags and environment variables with no single source of truth, which led to misconfigurations and made onboarding and support harder.

Key Features Introduced:

• One configuration file that provider operators edit in place of scattered flags and environment variables.
• Simpler documentation, support and automation for provider setup.

Work is code complete from the core team pending final implementation.

In-Flight Development

Several core initiatives that were actively developed during Q3 are excluded from this proposal and will be submitted in a future proposal once they ship. The largest is Provider Verification (AEP-86), whose core feature set was funded in the Q2 Core Engineering proposal (Proposal 333). The x/verification module is available in the node v3.0.0 pre-release and running on the provider verification testnet, which was opened for internal review at the start of the quarter. Work since then has focused on the specification, implementation and final testing ahead of a mainnet rollout. In the Q2 proposal we said implementation and testing costs would be included in Q3. Because that work has not yet been delivered, those costs move to the proposal following its release.

Alongside Provider Verification, the core team continued work on Lease Resizing, which will let tenants change the resources on a running lease without tearing down and redeploying. Further confidential compute work is also underway, extending AEP-83 with persistent storage and private registry support; full GPU confidential compute also requires NVIDIA licensing, which is in progress. Each of these will be scoped and costed in a future proposal once it is delivered.

Conclusion

Q3's core work widens what the network can offer and keeps its foundations sound. ARM64 support brings a new class of hardware onto Akash, and the mainnet releases of confidential compute and GPU interconnect make the network viable for sensitive and distributed training workloads. The Pyth migration kept the price feed behind the oracle and BME running through an upstream change, and the resilience work reduces its dependence on a single source. The CLI and provider configuration work make Akash easier to build on and easier to supply. Together these support provider growth, tenant adoption and the reliability of the protocol.

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.