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
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.
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_fee_collectornon_native_fee_collector_stakerstaker_fee_collectorCommunityPoolDenomToSwapNonWhitelistedAssetsTo- which then transfers this to the community pool, and remaining intaker_fee_collector.taker_fee_collectorare then attempted to swap to OSMO and the OSMO sent tonon_native_fee_collector_stakersThis 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_fee_collectornon_native_fee_collector_stakerstaker_fee_collectorauto_pol_fee_collectorand remaining intaker_fee_collectorauto_pol_fee_collectorattempts to swap 50% of the assets by denom to that specified in anauto_pol_denomparameterauto_pol_denomthen it should be returned totaker_fee_collector.auto_pol_fee_collectorto be retried the next epoch.CommunityPoolDenomToSwapNonWhitelistedAssetsTo, which then transfers them to the community pool, and remaining intaker_fee_collector.taker_fee_collectorare then attempted to swap to OSMO and the OSMO sent tonon_native_fee_collector_stakersThis requires 3 main parameter additions:
auto_pol_fee_collectorauto_pol_denomwhich controls the swapping target - this allows Osmosis to choose to accumulate OSMO paired pools or USDC paired pools.