AKT2.0 - Incentive Distribution Pool (IDP) and Sub-accounts

[lechenghiskhan]

Background & Context

This is the follow-up to the first set of AKT 2.0 implementations.

With nearly all forms of conceived take rates and the evolution of staking rewards described in AKT 2.0, those collected proceeds will be funneled first into the Incentive Distribution Pool (IDP) and further divided into sub-accounts based on some methodologies that will be discussed in this document and others to follow.

The IDP and its sub-accounts are important for accurately categorizing funds, but should not be too narrowly defined where their very implementation and use becomes a nuisance.

Prior discussions can be found here: IDP discussion on Github

Features and Definitions

1. Create the master module account above the current community pool called the Incentive Distribution Pool (IDP).
2. The community pool and subsequent pools will be subaccounts to the master Incentive Distribution Pool (IDP).
3. Incentives sub-account. This account covers incentives of all forms. The incentive label should be broad enough to cover uses like provider incentives, liquidity incentives, promotional incentives, and other incentives yet to be determined.
4. Developer Fund sub-account.
5. Security Fund sub-account.
6. All accounts should be able to hold, send, and receive all currencies that are supported on Akash Network. At the time of this writing, AKT and Axelar USDC (Osmo) should be the only currencies supported.

Flow of funds

This is not an ideal state as the entire flow of funds, methodologies, and mechanisms have not yet been detailed. This represents how the flow of funds should be given a reasonable extrapolation of our existing understanding with some broadly-contemplated future-proofing built in.

1. [Master account] Incentive Distribution Pool master account. It will house all sub-accounts to follow:
   a. Tenant and provider take fees from deployments paid in non-AKT currencies

   b. [Sub-account] Incentives Pool will hold

   • Provider subsidies. Subsidize providers to ensure the network has enough computing power to offer attractive prices to tenants.

   • Liquidity incentives. Liquidity pools like AKT/USDC on Osmosis or others that might become necessary

   • Deployment incentives. I think the inaugural use of this sub-account should be leveraged to grease the wheels of non-AKT (or all currency) deployments, effectively eliminating the need for any tenant to acquire AKT (as far as gas is concerned) to deploy on Akash Network via the following mechanism:

     • A small portion (perhaps 1% of all take fees from non-AKT deployments) can be converted to AKT via Osmosis and deposited here.
     • These fees will be leveraged, using AuthZ, to provide designated whitelisted accounts with gas-free deployments by paying for their gas cost from this account. This doesn’t just have to be leveraged for non-AKT deployments, but any deployment, effectively serving as Akash Network’s deployment faucet. This faucet will essentially become self-funded by deployment take rates.

   • Question(s) and thought(s):

     • We would have to periodically buy AKT using USDC so this account always has enough AKT to AuthZ gas. The initial oversight would fall to OCL. Should we consider a more automatic method of swapping in the future?
     • How do we enable users to automatically add their accounts to the whitelist? Is this through a web portal on Akash.Network?
     • Eventually, should we periodically purge this list or should we even do that? Should it be based on time or activity?
     • Do we need to designate/create purpose-built accounts within sub-accounts for things like “gasless AKT deployments”?

   c. All other IDP subaccounts will be created, but will be left blank for the time being. These other sub-accounts are: 1) public goods fund, 2) staking rewards, 3) community pool (already exists), 4) burning pool

   • Questions and thoughts:
     • Is a dedicated burning pool necessary? We can simply designate some portion of funds in a particular sub-account that should be burned. The counterargument for a dedicated burning pool would be cleaner accounting

Other details and questions

TBD

Current comparables

Comparables: how other projects use, design, and govern their community accounts.

1. Osmosis (community pool & grants program)
   a. About community spend and some resources https://github.com/osmosis-labs/governance/tree/main/community-pool-spend
   b. Best practices for crafting a proposal https://gov.osmosis.zone/discussion/3020-best-practices-for-drafting-proposals
   c. Retroactive report for grants program https://grants.osmosis.zone/blog/ogp-retroactive-report-q2-august-september
   d. FAQs and wallets for grant program (they have stables and OSMO) https://grants.osmosis.zone/resources
2. Juno: https://github.com/CosmosContracts/bounties
3. Comsos
   a. About the community pool https://github.com/gavinly/CosmosCommunitySpend
   b. About community spend https://forum.cosmos.network/c/hub-proposals/community-spend/27

Aside from Osmosis grants program and the report that was provided for that, there is very little visibility beyond looking back through proposals and figuring out how much is being spent. Another important distinction is that once the vote is passed, funds are transferred to the wallet provided based on the disbursement schedule (not requiring a multi-sig)

Implementation

Phase 1 - MVP

1. Create a master IDP module account
2. Redirect take rate funds from the community pool to the master IDP account
3. Nest the existing community pool as an IDP sub-account still named “community pool”
4. Create sub-account: Incentives
   a. Divert 1% of all take fees into this account to function as a faucet for deployments via AuthZ
5. Create sub-account: Security Fund (rewards distributed to stakers for maintaining the security of the network)
6. Create sub-account: Developer Fund
7. Create sub-account: Public Goods Fund

Phase 2 - Fast follow

TBD

Phase 3 - Bells and Whistles

TBD