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.

Summary

A dashboard that displays data, both numerically and visually, to exemplify trends and network health.

Motivation

The network usage dashboard will visualize data in charts, graphs, and metrics tracking the growth in deployments, providers, transactions, and resource utilization. This effort is largely inspired by one of Akash's leading community partners and winner of the Akash Deploy UI Challenge, Akashlytics.

Goals Increase adoption

Summary Add the ability for workloads to persist data between restarts, ideal for data intensive workloads such as blockchain nodes

Motivation Akash cannot support workloads that require data persistence between restarts. This prevents workloads with large datasets (such as blockchain nodes) from using Akash as it is not practical to download the data set for every restart. Ability to persist data between restarts helps solve this.

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.

Goals Reduce time to deploy and debug for power users (using the CLI)

Summary TTY Access allows developers to access the shell of the container that the application is running in. This provides the ability to easily debug.

Motivation Currently, debugging and running applications on Akash is difficult, as users can not run arbitrary commands on a running container. TTY access unblocks this and allows users to run any command.

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.

Goals Unlock new uses cases where workloads require standard ports and a dedicated IP address

Summary Dedicated IP addresses (and ports) for workloads and market place to source them.

Motivation Workloads hosted on Akash share IP addresses because there is no facility to assign individual IP addresses to applications. This presents limitations with routing. Hostname name based routing has to rely on HTTP or SSL. To accommodate for TCP / UDP, Akash assigns random ports and there is no way to multiplex TCP services over a single port.

This also slows down fault recovery as DNS services require record updates which are slow to propagate.

An ability to assign a dedicated IP address will solve this issue.

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.

Goals Reduce time to deploy and debug for power users (using the CLI)

Summary Ability to retain logs between restarts

Motivation Currently logs get lost when a container restarts as they are currently streamed from Kubernetes, and the retention period is too short to allow post-hoc analysis of what might have gone wrong with their deployment. This presents a problem with debugging as users cannot view logs when a container stops due to an error. Ability to retain logs during container restart solves this problem. Implementing this feature involves shipping logs from Kubernetes to a third-party log storage system such as Loki, and allowing Tenant access to these logs over a longer period of time than what is currently offered.

Goals Reduce time to deploy and debug for power users (using the CLI)

Summary AKCMD is a command-line utility that simplifies workload management on the Akash network. AKCMD is a complementary tool to core Akash CLI that focuses on improving tenant workflow by taking an opinionated approach to deployment on Akash Network.

Core Features

• Contextual Configuration: Reduces the set of command-line options needed for common operations by using config files that can be customized per project (same directory), per user (home directory) to Global (root).
• Text Output: Improves command line readability and user experience with clear, concise and readable outputs.
• Simple Deploy Workflow: Reduces the number of steps required to deploy. Features include preset preferred providers and price ranges.
• Interactive Onboarding: A rich interactive experience that provides feedback on SDL files (identifying errors etc) and provides information regarding the bid process.
• Simplified Installation: One line out of the box install across multiple platforms
• Keplr Wallet Integration: Reuse your existing Keplr wallet to ease user onboarding.
• Web UI integration: Rapid switching from terminal experience to a web-based experience to improve visualization
• Faucet Integration: Easily acquire AKT tokens from the developer faucet to reduce onboarding friction.
• Visualize Funds Distribution: Easily view funds in the wallet, escrows, and all the other places on Akash and other blockchains (IBC)

Goals Reduce time to deploy and debug for power users (using the CLI)

Summary Javascript SDK simplifies extending Akash in Javascript applications by providing libraries to improve access to the Akash API. The SDK also abstracts standard functions like credential management, retries, data marshaling, serialization, and deserialization.

Motivation Accessing Akash API requires writing wrappers for common function calls and logic. Users would incur enormous overhead costs before getting to work on what’s important -- the logic of the application. Javascript SDK eliminates the adoption friction point that requires more code, resulting in fewer bugs, and more time efficiency.

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.

Goals Empower development of Akash tools and features by simplifying extensibility using the Akash API

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

Goals

• Reduce time to deploy and debug for power users (using the CLI)
• Decrease time to deploy a new application by improving composability for SDL files with templatization. This enables configuration files that can then be shared and redistributed.

Summary Extendable SDL enables reusing configuration files by introducing normalization to avoid redundancy. Users can combine configuration from multiple files without making copies, allowing for faster, cleaner, and safer deployment. Users can share templated configuration files and align well with the DRY software principle.

Motivation Reusing SDL files between applications requires one to create copies and update configuration for ones. This redundancy is cumbersome and limits customization and it works against the DRY (Don't repeat yourself) principle.

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

Summary A GPU marketplace on Akash Network.

Motivation The lack of a GPU marketplace on Akash limits potential use-cases, and therefore adoption. GPU will open up new markets such as AI/machine learning, proof-of-work, and high performance computing.

Goals

• Reduce time to deploy and debug for power users (using the CLI)
• Enable users to estimate pricing

Summary A non-custodial web interface to manage applications on Akash.

Motivation Command-line interfaces alienate less advanced users and are not always easy to use, especially when visualizing large amounts of data. The deployment web interface will enable the adoption of Akash to beginner and intermediate users, thus growing the network.

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.

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

Summary Conditionally choose auditors to validate on a per-attribute basis.

Motivation The current SDL design limits a user to choose auditors that validate all attributes or none. Users cannot choose what attributes should be validated, by which validators.

Goals

• Increase visibility on the health of Akash by providing critical metrics in relation to system uptime and usage
• Allow providers to enable or disable selling compute on demand
• Providing tooling for the moderation of content

Summary A provider GUI that provides push-button management of pricing, supply, usage telemetry and the monitoring of health of the cluster.

Motivation Managing a provider on Akash is currently only available with CLI which is cumbersome and limited.

Goals Unlock new uses cases where workloads require standard ports and a dedicated IP address

Summary Overlay network connects workloads deployed on Akash in a private network with private IP space.

Motivation Workloads deployed on Akash that span across multiple data centers communicate over a public network. This puts an onus of securing the network on the user which is cumbersome and may lead to laxed security design. An overlay network exclusive for the applications solves this problem.

Goals Unlock new uses cases where workloads require standard ports and a dedicated IP address

Summary A container registry hosted on Akash with the sole purpose of storing Akash workloads addresses privacy, economic sovereignty and better control to Akash users.

Motivation

• Akash currently supports public docker containers hosted on external registries - workload containers must be accessible without authentication or authorization.
• Private registries are highly preferred to public containers as the latter can leak information about the inner-workings of a system or organization which would otherwise be kept secret.

Goals

• Simplify management of common services such as DBs
• Primitives for frictionless integration with - backend services
• Provide a pragmatic set of services at early phases to drive adoption
• Provide a federated experience by extending identity, operational, and user interface support to a diverse set of managed services that include services from decentralized and managed infrastructure ecosystems
• Provide a standard mechanism to decouple services from data to enable maximum possible portability such as DTP
• Provide necessary technical and operational support

Summary A permissionless market for Managed Backend Services (such as Databases) to reduce the operational burden for Tenants. The Managed Service Market (MSM) strengthens the Akash ecosystem by unlocking a new wave of service providers and enhances the liquidity of AKT.

Motivation

• Most modern application stacks consist of a multi-tier application-services stack (such as databases, caches, etc).
• Standard services such as databases, when managed by specialized service providers that understand how to scale and secure the service being used by the tenant, significantly simplifies operations and thereby costs for the tenants.
• MSM enables creators of software to generate meaningful income while improving their work and keeping the software open. Today, the value capture is at a massive imbalance where Cloud Service Providers (CSPs) are the biggest benefactors. MSM balances this asymmetry.