Feature A publicly accessible dashboard that displays usage statistics and availability capacity for the network with historical lookback.

Motivation The best way to get new users to trust Akash is to show proof that others have trusted it.

Feature Offer tenants the option to persist data for their workloads, even when the workload restarts

Motivation Not being able to save data and state between restarts limited the range of applications and workloads that can be deployed on Akash. Allowing persistence of stored data helps drive wider adoption of the Akash cloud.

Read documentation here

Goals

• Increase adoption
• Increase liquidity

Summary Faucet enables new Akash users to easily acquire small amounts of AKT to let them deploy on Akash.

Motivation Acquiring AKT tokens to deploy is hard as a user must go through a centralized exchange (CEXs) that mandates lengthy KYC / AML procedures. Though AKT is available on Decentralized Exchanges that do not require KYC / AML checks, they still need users to have other crypto-assets like ATOM that need to be acquired using CEXs. These friction points significantly hinder onboarding, especially to a user that wants to try out Akash.

Goals Provide tooling to improve observability and reporting on usage

Summary Hostname migration allows a tenant to migrate their custom hostnames from one deployment to another. This allows for canary deploys, scaling, re-pricing, and many other workflows.

Motivation

So-called "custom hostnames" allow for requests to tenant-specified hostnames to be routed to that tenant's services. Currently, there is no way to change which deployment a hostname is bound to - if a tenant wants to route requests for a hostname to a new deployment, they must first tear down the original deployment, which can cause disruption for their deployed service.

Hostname migration allows for a tenant to re-bind a hostname to a new deployment without tearing the original deployment down. This unlocks many workflows that are sensitive to disruption (websites, API endpoints, etc...). For instance, this feature allows for the following operations without disruption:

• Fast-rollback when deploying a new application version.
• Scaling deployments up or down.
• Re-pricing deployments by obtaining new leases.

Goals Simplify governance on Akash blockchain

Summary On chain inflation decay cursive ensures inflation decay occurs every block period without needing governance proposals.

Motivation Currently, inflation for the AKT token is not dynamically set and relies on a small set of variables that require constant vigilance, management, and oversight via governance proposals to ensure our maximum supply of ~389mm AKT is not exceeded AND to ensure that AKT supply tracks closely to the curve described in the economics whitepaper.

Furthermore, as things currently stand, the reliance on constant governance proposals is not sustainable, especially as the company’s total share of AKT and voting weight will continue to wane. As the company’s voting weight decreases, so too will its ability to drive the outcome it wants due to continued decentralization.

Implementing a dynamic decay function to manage inflation without oversight relieves the company from having to worry about and plan constant governance proposals, using political and reputational capital to push proposals through that could be allocated elsewhere.

Feature Allow access to the shell of a container to run arbitrary commands (supported by the liux version of the shell).

Motivation Debugging application issues is difficult without the ability to run commands on the container shell.

Read documentation here

Goals

• Allow users to easily liquidate their earned AKT by increasing liquidity (and options)
• Reduce time to acquire AKT for new users
• Reduce churn rate for existing users by reducing friction in acquiring AKT

Summary The Ethereum Bridge enables AKT users to acquire AKT using various ERC-20 tokens (USDT).

Motivation

• By enabling users with more options to buy and sell AKT, we can increase liquidity, eliminate friction points found in the new developer onboarding process, and attract additional AKT buyers and traders from the crypto retail market.
• Additionally, this will increase our likelihood of working with Tier 1 exchanges and DEXs like Uniswap.

Goals Unlock new uses cases such as ML by adding ability to source GPUs

Summary Marketplace to consume unbounded network bandwidth for workloads running on Akash.

Motivation Workloads running on Akash have a fixed cap with bandwidth usage. This prevents data intensive applications from using Akash. Removing this limit by creating a bandwidth market enables more use-cases for Akash.

Feature The UI component library is an open-source repo of code components, such as cards and buttons, that empowers the Akashian community to efficiently produce on-brand websites and applications.

Motivation The UI component library allows Akash to scale massively, empowering community members to directly build tools, rather than using the bandwidth and resources of one individual company. Because engineers aren’t always designers, their Akash initiatives have inconsistent branding and UI experiences, leading to confusion and mistrust from users.

Goals Enable Transport Layer Security with SSL

Summary SSL support allows users to attach x.509 certificates to workloads. Users can bring their own certificates to use auto-generated certificates for simplicity.

Motivation Akash currently does not provide a mechanism to attach x.509 certificates to workloads and defers to an external router (Cloudflare) to provide SSL capability. This introduces additional friction as one is required to find external support.

Feature Allow reusing of configuration files (SDL) thereby improving code use and enabling code sharing.

Motivation Being able to leverage previously built config files in a modular fashion improves developer productivity and also aligns with a fundamental DRY (Don't Repeat Yourself) principle of software engineering.

Goals

• Compute provider on Akash should be able to capacity plan more easily
• Provide financial analysis and revenue visibility for providers

Summary A provider onboarding framework to ease new providers selling compute on Akash

Motivation Currently, there is an enormous and intricate set of steps that a provider needs to execute in order to provide compute on the Akash Network. This leads to confusion and instability of the provider. A new provider onboarding framework will increase adoption, optimize the onboarding process, and eliminate potential issues with the provider into the future.

Goals Communicate system architecture, important concepts and value propositions

Summary The developer hub will be one stop shop for all developer related content such as guides, tutorials, documentation, architecture and discussions.

Motivation The Akash community produces an immense amount of technical content, both long and short form --  however, these initiatives are scattered across different mediums, making it difficult to both find and keep them updated. The developer hub will centralize an index of community generated content (CGC), enabling us to leverage resources outside of the company and scale.

Feature Allow tenants to request public IP addresses for services deployed on Akash.

Motivation A fixed IP address is essential before several new types of workloads and applications can run on Akash infrastrcture.

A fixed public IP also allows services to use known & desired ports, including those from the standard range (like VPN for example).

Goals Provide users with stability with computing prices

Summary Ability for users to renegotiate the AKT price without breaking the lease.

Motivation The volatility of AKT leads to unstable value exchanges, as the AKT denominated price is set during lease creation and doesn’t change until the lease terminates. When the dollar AKT is higher than it was during lease creation, it may benefit the provider at the cost of the tenant and vice versa. An ability to renegotiate the lease during its life cycle solves this issue.

Feature Retain logs through container restarts, likely using a 3rd party log retention service.

Motivation Retaining logs through container restarts is crucial to analyzing failures and improving reliability of applications that run on Akash.

Feature Updated Command-Line-Interface (CLI) that streamlines tenant deployment.

Motivation Reduce time to deploy for power users by offering a more streamlined approach to deploying a workload on Akash.

Feature Offer libraries and ready to use examples of common functions for developers building applications usin the Akash API.

Motivation Like any public APIs, utilizing the Akash API requires developers to write wrappers for common function calls and logic. Offering standard functions like credential management, retries, data marshaling, serialization/ deserialization and more as libraries and examples, reduces dev time and bugs, thereby increasing developer adoption of the Akash API.

Read documentation here

Feature Ability to source GPUs on the Akash marketplace and deploy workloads on them

Motivation Supporting GPUs on the Akash marketplace will open up new markets based on use cases such as Machine Learning, Artificial Intelligence, Proof-of-Work (PoW) and High Performance Computing (HPC) applications.

Feature A web based, low friction interface for deploying workloads on Akash.

Motivation For Akash to expand beyond its current user base of deeply technical developers familar with Kubernetes, YAML & SDL, it needs to provide a way for less technical users to get started & quickly find value.

Goals Improve ability to filter provider attributes effectively so tenants can clearly understand various deployment options and effectively filter according to their needs.

Summary Incentive mechanism to attract and retain Auditors on Akash.

Motivation Akash audited attributes allows for anyone to audit a provider’s attributes and publish results onchain where tenants choose to trust. Currently, auditors have no direct incentives, making it difficult to attract new auditors. This challenges decentralization by consolidating power to a few auditors, instead of the many.

Feature Allow tenants to decide which attributes they would like validated by an auditor.

Motivation Not all tenants care about every provider attribute equally. Offering tenants the ability to filter on specific attributes when looking for provider validation increases the number of providers they get, thereby driving adoption.