Core Engineering – Q2 2026 Funding Proposal

[isaac9905]

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

This proposal seeks community approval to fund the Overclock Labs core team for the protocol and provider-level engineering delivered during Q2 2026. Built on the Akash chain's Cosmos SDK v53 and BME on Akash foundation, this work spans the Oracle v.2, automated resource reclamation, confidential computing, on-chain provider verification, and InfiniBand support.

The AEPs and initiatives covered by this proposal are:

• Oracle v2 add on to AEP-80
• AEP-82: Resource Reclamation
• AEP-65 / AEP-83: TEE / Confidential Computing via Kata Containers
• AEP-86: Provider Verification Core Development
• Infiniband on Akash

Motivation

This work strengthens the economic foundation and provider infrastructure required to scale the network.

• Oracle v2: Provides the essential timestamp-based pricing primitives for future tokenomics.
• Resource Reclamation: Maximizes provider utility via a new, efficient recovery mechanism.
• Confidential Computing: Establishes Akash as the first decentralized cloud with production-grade TEE support.
• Provider Verification (AEP-86): introduces an on-chain trust model that lets tenants select supply by verified tier.
• InfiniBand: Unlocks large-scale distributed AI training and high-performance hardware profiles.
  Together, this work advances Akash along two axes: strengthening the on-chain economic primitives required for sustainable, usage-aligned tokenomics, and expanding both the trustworthiness and the range of network supply.

Both Oracle v2 and resource reclamation were a part of the Mainnet 18 upgrade.

Total Request

For the Q2 2026 Core Engineering Proposal, Overclock Labs is requesting $292,581 from the Community Pool for work directly attributable to the core AEPs for this period, alongside a 44.7% AKT volatility buffer.

	Request from CP
Engineering hours	1,361.14
Engineering rate per hour	$147.11
Engineering total cost	$200,237
Support hours	12.57
Support rate per hour	$156.01
Support total cost	$1,961
Labor Subtotal	$202,198
AKT Volatility Buffer (44.7%)*	$90,383
Total Request	$292,581

*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
Oracle v.2	305.72	$58,180.58
As a percentage of total labor budget	22.26%	28.77%
Resource Reclamation (AEP-82) - Core Development	110.57	$20,987.49
As a percentage of total labor budget	8.05%	10.38%
Confidential Compute via Kata Containers (AEP-83) - Core Development	589.71	$66,243.85
As a percentage of total labor budget	42.93%	32.76%
Provider Verification (AEP-86) - Core Development	289.71	$43,913.81
As a percentage of total labor budget	21.09%	21.72%
Infiniband on Akash	78	$12,872.52
As a percentage of total labor budget	5.68%	6.37%

AEP Summary

On-Chain Oracle Module (Oracle v2)

Problem Addressed: The Oracle v1 pricing model was tied to block height, which made staleness detection, TWAP computation, and price querying dependent on block cadence. Reliable, real-time AKT/USD price data is a prerequisite for on-chain settlement and downstream tokenomics.

Key Features Introduced:

• Replaces block-height-based pricing with wall-clock timestamps and durations, making staleness detection and TWAP calculation independent of block cadence.
• Time-Weighted Average Price computation with timestamp-based staleness and deviation health checks.

AEP-82: Resource Reclamation

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

Problem Addressed: Avoiding disruption to tenant workloads by introducing a grace period or advanced notice termination to the tenant.

Key Features Introduced:

• Negotiated reclamation window — a wall-clock grace period agreed between tenant and provider at bid time and stored on the lease. Tenants can require a minimum window in their SDL, and providers must offer a window that meets or exceeds it to win the bid.
• New Reclaiming lease state with a new msg type — a provider initiates termination by sending this message, which moves the lease from Active to a new Reclaiming state and sets a deadline. During the window the provider is blocked from closing the lease, the tenant can close anytime, and payments continue at the full rate.
• Governance-bounded window limits — two new market-module parameters, min_reclamation_window (default 1h) and max_reclamation_window (default 720h / 30 days), cap the allowed durations, so both tenant requirements and provider offers must fall within community-set bounds.

AEP-65 / AEP-83: TEE / Confidential Computing via Kata Containers

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

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

Problem Addressed: Tenants running sensitive workloads had no way to guarantee hardware-level isolation of their data in memory on a decentralized provider network, blocking adoption for security-sensitive and regulated use cases. Feature is currently LIVE on this provider.

Key Features Introduced:

• Automatic provider capability advertising and runtime selection — the provider's inventory service auto-advertises confidential-compute and the CPU TEE type (intel-tdx / amd-sev-snp) when it detects Kata runtime + TEE-capable hardware, then transparently injects the correct Kata RuntimeClass (e.g. kata-qemu-snp, kata-qemu-nvidia-gpu-snp) into the pod — no tenant image changes.
• GPU confidential computing with composite attestation — NVIDIA H100/H200 passthrough into the Kata micro-VM with CC-on mode (encrypted PCIe traffic), where the CPU TEE is the trust anchor and the tenant verifies both CPU and GPU through a single composite attestation token (via Intel Trust Authority + NVIDIA's attestation service).

AEP-86: Provider Verification

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

Problem Addressed: Tenants have no trustworthy, on-chain signal for provider quality or authenticity, making it difficult to select reliable supply for production workloads.

Key Features Introduced:

• On-chain provider verification with a tiered trust model (L0–L4). Providers register and governance-approved auditors record attestations on-chain.

• New x/verification module, provider registration and maintenance notices in x/provider, and an x/market bid-filter adapter with lease statistics.

• Provider inventory collector with signed snapshots and a static host-probe binary (akash-inventory).

• Tenants can filter bids by verification tier; Console surfaces provider trust levels (Console work covered under the Client Engineering proposal).
  Additional Notes:

• This inclusion of AEP-86 is for the core feature set development. Implementation and final testing costs will be included in the Q3 2026 props.

InfiniBand on Akash Providers

Problem Addressed: Large-scale distributed AI training requires high-speed, low-latency interconnect between GPU nodes. Without RDMA fabric support, Akash could not host multi-node GPU cluster workloads that depend on InfiniBand.

Key Features Introduced:

• InfiniBand high-speed RDMA interconnect support, enabling multi-node GPU cluster networking for distributed training.

• Providers with Mellanox / NVIDIA ConnectX HCAs advertise RDMA capacity; the inventory operator discovers GPU interconnect capacity.

• Tenants request interconnect groups in SDL to land co-located pods with IB fabric access.
  Additional Notes:

• Final development and implementation is complete. Roadmap AEP and provider release is pending.

Conclusion

The Q2 2026 core engineering work delivers the on-chain and provider-level infrastructure that positions Akash for its next phase of growth. The Oracle v.2 (AEP-80) and Resource Reclamation (AEP-82) strengthen the chain's economic primitives and provider utilization. Confidential Computing (AEP-65 / AEP-83) opens the network to security-sensitive workloads. Provider Verification (AEP-86) expands the trustworthiness of new providers listed on chain and the introduction of InfiniBand expands addressable workloads on Akash.

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.