Proposal #233
Passed on 23 May 2022 with 94.9% of the votes for yes.
Yes
94.9%
99.9% without abstain
Veto
0.0%
of votes cast
Ended
23 May 2022
94.93%
of votes cast
5.02%
of votes cast
0.04%
of votes cast
0.01%
of votes cast
n [Hidden link]
This proposal entails two sub proposals.
That we overhaul the meta process for generation of adjustment proposals. This has historically been implemented through a series of google spreadsheets implementing each variant of the mechanism, with static copies made for the generation of each proposal. This shall be replaced with a Github repository based process, which will make public tracking of changes easier, and allow for (nearly) full automation of the proposal generation process.
That we modify the current mechanism (bias, subsidy, matching, fee cap, etc) to first group pools into categories, each with a parameterized incentive share, and then pools within each category split that share based on their share of fees collected and external incentives.
[Hidden link]
This Github repo will at all times contain at least 3 branches, which (along with some Github Action workflows), serve to automate the process of creating weekly adjustment proposals.
The main branch contains the process and data for the most recent proposal.
The staging branch contains the process for the next proposal.
Throughout the week, PRs are made to staging corresponding to on chain text proposals, such as adding pools to onboarding, matching external incentives, or changing the adjustment process.
A liveview branch off of staging is continually updated with new data, so that we can see what we expect the next proposal to look like.
As on chain text proposals pass, their PRs are merged to staging (and then merged to the liveview branch on the next update).
When it is time for a new adjustment proposal, the liveview branch is merged back into staging (giving it up to date market data). And then staging branch is merged into main.
The data in the main branch is then used to create the on chain adjustment proposal.
This model groups pools into a number of categories with proportional incentive shares, so that we can prioritize certain classes of liquidity directly.
The share of incentives allocated to each category is then split according to the proportion of swap fees collected by each pool within the category. These values are limited by the swap fee cap (currently 3), such that pools will not benefit by having more than 3x the average fee APR of the category.
We then recalculate shares using (capped) fees + external incentives collected by the pool. To limit the incentive increase caused by a match relative to the base incentives, we take the minimum of this adjusted reveneue share, and (1 + matched_multiple_cap) * capped_fee_share. We set matched_multiple_cap at 1, so set matches to be no more than the base incentives of a pool.
Qualification for Major status is determined by governance based on a combination of factors, namely:
OsmoThis proposal also entails choosing ATOM, WETH, WBTC and CRO as starting Major tokens. As well as USDC, DAI, and EEUR as stablecoins.
Pools can also have a minimum share set by governance, to incentivize liquidity ahead of observed trading volume. We set minimums of 25% of incentives on pools 1 and 5% on pools 674, 704, and 712 as demonstration and to guarantee a large amount of incentives for base liquidity. These parameters would be set and changed by governance and should be used to prioritize the growth of strategic liquidity.
These initial category shares were chosen to approximately match the current breakdown of incentives between these groupings, but should be changed over time with follow up text proposals as needed. (And will likely be adjusted along with proposals to add incentives to new pools in the category)