AKT2.0 - Stable payments & Take rates

[lechenghiskhan]

Background & Context

Currently, the only supported form of payment and settlement on Akash Network is the network’s native AKT coin. This creates several challenges for both providers and tenants that include, but are not limited to the following:

Tenant challenges

1. Lack of price stability. This leads to tenants having difficulty understanding their costs and planning potential spending ahead of time due to the inherent price volatility of AKT.

2. Acquiring, using, and holding an alternative asset. Tenants have to go through the process of acquiring and holding AKT, which is not as widely accessible or as well-understood as USDC.

Provider challenges

1. Lack of price stability. It becomes difficult to consistently and reliably forecast revenues due to the inherent price volatility of AKT.

2. Holding and liquidating an alternative asset. Providers have to understand how to handle, custody, and ultimately liquidate AKT earnings in order to realize revenue.

Collectively, these challenges make it difficult for Akash Network to acquire tenants and providers who don’t have, don’t understand, or don’t wish to acquire/hold AKT.

Stable payments aim to assuage resource planning concerns around a volatile alternative asset, making the experiences for both providers and tenants on Akash Network more consistent and accessible. This will clear the path for more tenants to deploy more workloads to Akash Network and make the value proposition for providers clearer while lowering the barrier to entry for both. Supporting native USDC will enable greater access across the board for both sides of the marketplace.

How does this feed into AKT2.0?

AKT 2.0 is a massive undertaking that encompasses economics, incentive theory, and public goods design just to name a few. This PRD aims to tackle one of the single biggest components of AKT 2.0: stable payments & the take rate.

Desired user experience

Phase 1 - MVP

This should be the absolute minimum viable build we need to get this off the ground and implemented as rapidly as possible. This phase should only include:

1. USDC support natively.
   • Payment and settlement will be in the same currency. USDC -> USDC or AKT -> AKT. No swapping.
2. Basic and simplest form of the take rate: deduct 20% from the provider’s settlement. Providers will just have to price their bids higher to accommodate.
3. Module account with no multi-sig distribution and only governance control. Not sure if this is needed for phase 1 or if it can be held back for later if it increases speed.
4. USDC transactions will still use AKT for gas.

Phase 2 - Fast-follow

1. Enable on-chain governance to distribute or swap for and burn AKT if this wasn’t enabled in phase 1.
2. Enable a "gas-less" deployment experience leveraging an AuthZ faucet funded by take rates.

Phase 3 - Bells and whistles

ALL phase 3 enhancements should be low-priority items until other, more pressing features of AKT 2.0 are implemented.

1. Atomic swap capabilities.
   • At the account module level in order to enable auto-burn, if desired at a later date.
   • At the account level for tenants so that tenants who wish to pay in USDC don’t have to go out of their way to acquire AKT just for gas.
     • Another implementation here could be to enable gas-less transactions for USDC deployments b/c of the high take rate.
2. Allow cross-currency payment and settlement (pay in USDC and settle in AKT, for example).
3. Enable two-sided take fees so it comes from both tenants and providers vs just providers.

Feature/capabilities list

These are not exhaustive and listed in no particular order.

1. Onchain USDC support (axelar)
   • Enable the SDL to support USDC
2. Osmosis dex integration
   • Price oracle(s) to determine price of AKT<>USDC
   • Auto swap to enable
     • Gas fees for both tenants and providers w/o having to acquire AKT.
3. Gasless transactions for genesis operations where users’ wallets need some dust AKT to perform their first operations. How do we get around this challenge?
   • First operation is creating a certificate.
   • Is AuthZ gas the feature/module from the Cosmos SDK that we need?
4. Create module account to hold take rate (should this account be the start of the IDP?)
5. Take rate
   • Single-sided take rate (upon withdraw by providers)
   • Dual-sided take rate (tenants upon deposit + upon withdraw by providers)

Final Specification [Draft]

This spec outlines the features and details for phase 1 of the stable payments enhancement set, which includes: stable payments, settlements, and take rate. This is an MVP with further phases to follow that will be defined and scoped shortly after the completion of this spec.

USDC implementation

1. Only Axelar USDC on Osmosis will be the stable currency supported on Akash Network to start.
   
   Versions to be left for future discussions: Axelar USDC directly on Akash Network, Gravity USDC, issuance chain USDC.
2. We also benefit from the Kado onramp Osmosis already supports:
   
3. Wallet support (Keplr). Akash Network’s implementation of USDC should mirror what is currently supported by Keplr for Osmosis, which includes the ability to view, send, and receive USDC with gas paid in the native coin.
4. Create a table of supported currencies and their respective take rates that can be updated by governance proposals. The table should look like this for phase 1 of this implementation.

   Currency	Take Rate
   AKT	4%
   Axelar USDC (Osmosis)	20%

Take rate

1. Initial USDC take rate is set to 20%.
2. To be executed only upon withdrawal of funds by providers.
3. Take rates should be unique to each currency (see table above) and should be adjustable by governance independent of each other.

SDL & Escrow

1. Currency selection to be enabled in the SDL where the tenant can designate a specific currency like AKT, USDC, or ALL.
2. Tenants should be able to query for providers based on currency parameters (USDC or AKT).
3. Escrow accounts should be able to house and interact properly with USDC.
4. Escrow minimum amounts need to be defined for each new currency. AKT is uAKT, what’s needed for USDC?
5. Providers should be able to bid on leases based on currency. If a provider only wants to bid on jobs paid in USDC, they can filter out AKT jobs.
6. Enabling provider settlement in USDC from escrow. This is probably redundant with a previous point, but calling out for completeness.

Module account update (community pool)

1. Ensure support for Osmosis’ version of Axelar USDC. This means the ability to hold and interact (send and receive) this version of USDC.
2. USDC balances, transactions, and history should be visible on block explorers.

Network Upgrade

1. Required because of state change.
2. Testnet(s): probably requires two testnets per Artur (one for Akash and one for Osmosis)

Education

1. Providers need to be educated about the take rate and how they should incorporate this added cost to their pricing methodologies.
2. Tenants might need to be educated that there are potential cost benefits to paying for jobs in AKT vs USDC b/c providers will charge more to compensate for the take rate applied to their revenue.
3. Ecosystem partners: praetor, cloudmos, spheron, etc should be educated.
4. Once a spec is finalized and posted on our GH, we can open up a simultaneous discussion thread on GH and discord to answer any questions, receive ideas and feedback, and address concerns.
5. Vanguards and insiders should be educated and equipped to help answer questions.
6. Documentation. Updated documentation for this is probably necessary.

Marketing GTM

1. Once the spec is live on Github, create Twitter thread laying out the high-level details with a link to the spec on Github.
2. Cross-post the thread to all of Akash’s other social channels (Telegram, Reddit, Discord).
3. Host a community-led AMA discussing the mechanics of the features, potential use-cases, and impact on the network.
4. Condense AMA content into a blog post, which will be posted to akash.network and amplified on social.

[Aihonaken]

Hi ! This is a really great proposal. I like the take rate stuff, but have a few questions. Now, i'm not a mush of a tech expert, so really sorry if my questions will look silly.

• Will the provider's prices still be competitive with a 20% take rate? What i mean by that is that Akash position itself as a cheaper solution, will we still remain the one?
• I do understand where USDC take rate will go (to buy back the AKT and burn it), but i don't understand where the AKT take rate will go? To the governance wallet, or burned as well?
• Why AKT has a 4% take rate? aren't 0 or 1% take rate will be a much of a booster for community to switch from USDC to AKT in the later stages?

Thank you for the time and effort of creating the proposal. Was enjoying reading it.

[lechenghiskhan]

Great questions and no worries at all! Every question is welcome :)

1. I think the provider price will still be competitive for a few reasons: a) prices are generally 50%+ cheaper vs similar via CSP, b) part of the take rate will go back into potential incentives and subsidies, which reduces overall costs
2. Both take rates in this iteration will go into the community pool. Whether or not proceeds taken are burned will be left for a later stage of discussion and governance. The use cases for the taken proceeds can range anywhere from funding incentives to burning to subsidies; something we'll solve at a later date and time.
3. AKT should have a take rate regardless b/c value driving mechanisms have to exist in order for the ecosystem to flourish. 0% is a nonstarter b/c at some point, the system has to become economically self-sustaining. 4% is just my proposal in this case and it can be changed at future points in time via governance!

Thank you so, so much for drilling so deep. If you'd like to be more involved or discuss things asynchronously, please drop into our Discord: https://discord.gg/akash (wg-stable-payments).

[cloud-j-luna]

Great proposal!

1. I'm trying to understand the need to have the price oracles. Isn't USDC supported by IBC? Couldn't we just transfer the USDC directly to the provider's Akash Network address? I might be missing some context as I'm not too familiar with IBC.

2. Currently in the SDL files we specify an amount of uAKT per block. How would this work with USDC? it's a fraction of cents which might be hard to grasp. When scaling how we will address this same question for ATOM, ETH, BTC, ... Should we define a standard for per-block units or higher intervals?

[lechenghiskhan]

Apologies for getting to this so late! Happy to answer your questions and thank you for asking:

1. You're totally right. The actual implementation of USDC doesn't require a price oracle. We have to support the asset natively on Akash, which is the path being pursued.
2. In terms of how we display pricing that's at fractions of a cent, that's a great question. I think having dollar-denominated pricing that is consistent with the denomination users pay in is critically important, even if the amounts are small. As far as other currencies and how we display them, the quotation price should always be reflected in dollars while the native unit of crypto should be also visible.