[Feature]: Auto Protocol Liquidity Whitelist for Taker Fees

[JohnnyWyles]

Summary

Osmosis has limited choices when choosing what to do with collected taker fees. Non-OSMO taker fees are either stored in the community pool until a governance proposal triggers their use or disposed of for OSMO for onward distribution to stakers. This issue proposes adding a third option of automatically using a set of assets to grow protocol liquidity in an, as yet to be governance approved, list of assets, likely those with high volume-to-liquidity ratios. This would improve execution costs for traders and further increase the volume of the asset, causing a feedback loop on the taker fee collection by the trading of the asset.

Problem Definition

There are several assets collected by Osmosis with high volume-to-liquidity ratios that could benefit from increased liquidity in the pools but are not attracting liquidity rapidly enough. Osmosis is collecting the assets from this volume that could be used to increase this liquidity, but regularly disposing of them for staking rewards. This feature would enable Osmosis to begin automatically increasing liquidity with these assets, improving the trading execution rate and becoming a more attractive location for trading. The main disadvantage of this feature is that list additions would likely be from assets that are currently being sold to OSMO for staking rewards - lowering staking rewards until the asset is removed from the list, but in theory increasing them in the longer term.

Proposed Feature

Existing flow is as follows:

• Taker Fees are collected on trades and accumulate in taker_fee_collector
  • OSMO is sent to non_native_fee_collector_stakers
  • Quote assets are split between the community pool and remaining in taker_fee_collector
  • non-Quote, non-OSMO assets are split between attempting to swap to the CommunityPoolDenomToSwapNonWhitelistedAssetsTo - which then transfers this to the community pool, and remaining in taker_fee_collector.
  • All remaining assets in taker_fee_collector are then attempted to swap to OSMO and the OSMO sent to non_native_fee_collector_stakers

This issue would insert another step (Similar to how the request that the Quote list above be changed to a separate whitelist in https://github.com/osmosis-labs/osmosis/issues/7984)

• Taker Fees are collected on trades and accumulate in taker_fee_collector
• At epoch
  • OSMO is sent to non_native_fee_collector_stakers
  • KeepWhitelist assets are split between the community pool and remaining in taker_fee_collector
  • POLWhitelist assets are split between a new module account auto_pol_fee_collector and remaining in taker_fee_collector
    • auto_pol_fee_collector attempts to swap 50% of the assets by denom to that specified in an auto_pol_denom parameter
    • Each denom is then attempted to add liquidity to the paired pool specified in the whitelist. If the denom has no pairing present and is not auto_pol_denom then it should be returned to taker_fee_collector.
    • Any leftovers remain in auto_pol_fee_collector to be retried the next epoch.
    • The representative token received from this should be sent to the community pool. This mechanism should initially only use pool-based vaults (Astroport) rather than continually creating new position IDs.
  • Non-KeepWhitelist, non-POLWhitelist, and non-OSMO assets are split between attempting to swap to the CommunityPoolDenomToSwapNonWhitelistedAssetsTo, which then transfers them to the community pool, and remaining in taker_fee_collector.
  • All remaining assets in taker_fee_collector are then attempted to swap to OSMO and the OSMO sent to non_native_fee_collector_stakers

This requires 3 main parameter additions:

• New module account of auto_pol_fee_collector
• A new whitelist that accepts denom:pool pairings.
• A new param of auto_pol_denom which controls the swapping target - this allows Osmosis to choose to accumulate OSMO paired pools or USDC paired pools.