Disposition of ProtoRev Collected Revenues - Burn

Proposal Discussion
1

Original Thread: Commonwealth

This proposal seeks to determine the disposition of all past and future revenues collected by the ProtoRev module (apart from those already allocated to the Skip Protocol developer wallet). The proposed distribution is as follows:

  • Non-OSMO tokens will be sent to the Community Pool.

  • Any OSMO will be burned.

Background

The ProtoRev module came into use in v15 of Osmosis, providing a mechanism by which the protocol automatically rebalances arbitrage opportunities between liquidity pools, and the resultant revenue is stored in a holding account until governance decides the use.

For the last three months, ProtoRev has consistently been collecting approximately 1250 dollars worth of tokens per day.

ProtoRev value generation is currently proportioned as 3 OSMO to 1 Non-OSMO but may shift over time.

Proposal

This proposal signals community consent for the following:

  • Distribute all past and future non-OSMO revenues collected by the ProtoRev module to the Osmosis Community Pool
  • Burn all past and future OSMO revenues collected by the ProtoRev module to implement a potential deflationary mechanism for Osmosis.
  • Make future changes to the distribution of these revenues governance adjustable parameters.

Distributions of revenue to the Skip Protocol developer wallet are exempt from this proposal. The revenue share collected by Skip Protocol will continue to be distributed according to the fee structure outlined in Proposal 341.

Rationale

Non-OSMO Token Usage

Non-OSMO tokens are a premium asset for the Osmosis chain as they represent revenue divorced from OSMO inflation.

They also have greater flexibility in usage by the protocol compared to having a solely monolithic community pool, able to earn further yield, replace requirements for rental through protocol liquidity or perform community spending without the inflation concerns of using the native token. Therefore it would be best for Osmosis to retain these tokens in the community pool to diversify and facilitate such uses.

OSMO Usage

OSMO obtained via ProtoRev is effectively burned if it does not re-enter circulation. The potential to enter circulating supply is not a deflationary model, as the maximum supply remains at 1 billion.

Burning the OSMO remaining in the ProtoRev wallet confirms that it will not re-enter circulation and establishes a deflationary mechanism for Osmosis. This mechanism will likely take a long time to become net deflationary, relying on the thirdening of Osmosis inflation and increased levels of ProtoRev generated. However, it would grow in efficacy as the network matures and volume increases.

Why not send it to the community pool?

The community pool currently contains 85 million OSMO. It receives additional OSMO in the form of 5% of inflation and revenue from specialized transactions such as creating a pool or an external incentive gauge. Therefore the community pool has little use for this additionally collected OSMO, which instead can be used to provide a new and potentially escalating mechanism that feeds into the overall Osmosis tokenomic model.

Why not send to stakers?

This proposal argues that implementing a variable burn mechanism for Osmosis has more long-term potential for tokenomic impact than distributing it to stakers for a small APR relative to the planned share of Taker Fees assigned in Proposal 530.

ProtoRev is expected to yield 0.16% APR compared to the Taker fee of 3.95%.

Rather than boost the yield of stakers slightly, a novel mechanism should be explored.

Why burn?

A burn mechanism makes non-staking OSMO positions more attractive as it offsets inflation and cancels the inherent opportunity cost or impermanent loss incurred by these positions.

Pools may shift away from OSMO pairings after the deployment of Supercharged liquidity pools when swap fees again stable tokens will likely be sufficient to support liquidity. The changing ratio of liquidity pairings will likely impact the OSMO ratio of revenue that ProtoRev generates.

The development of a burn mechanism requiring OSMO pools to exist incentives the maintenance of OSMO pools from sources such as the Community Pool’s reserves in pairings with the non-OSMO tokens received from ProtoRev and Taker Fees. The larger these positions are, the more OSMO will continue to be generated from ProtoRev originating in these pools, causing the incentivized protocol liquidity and remaining OSMO held in the community pool to benefit from the deflationary system.

Comparison to Previous Burn Proposals

Proposal 516 asked that the non-OSMO assets used by the protocol be used to purchase and burn OSMO. While this provides buy pressure on supply, it is only around a quarter of the revenue collected through the ProtoRev module at the expense of assets that Osmosis currently has no other method of obtaining without arranging a token swap or purchase through intermediary multi sigs.

Proposal 519 also asked that non-OSMO assets are transferred to the community pool but also requested that a compensatory value of OSMO be burned. This additional burn mechanism may have eventually exceeded the income of the community pool in OSMO, and so needed later intervention or more complex mechanisms to ensure this was not excessive.

Implementation

Implementation will take place during a future software upgrade.

As the Skip dev account takes its share every block as of v16, any leftover OSMO can be burned at the end of the transaction rather than deposited into the holding address. If the resulting asset is a non-OSMO denom, it will be sent to the community pool instead.

As part of this implementation, all existing assets in the holding address would be processed and burned or sent to the community pool according to their type.

2

Transferred Comment

RedRabbit33
osmo1hxfd

•

6/29/2023

Not the best logic models, but they perhaps are enough to effectively communicate how I see things.

image
image601×771 58.5 KB

3

Transferred Comment

Johnny Wyles
osmo1

•

6/30/2023

Which is the community tax being burned here?

I think pay for performance is great because of this model, but should come from something directly increased by apps such as gas fee shares.

4

Transferred Comment
Leonoor’s Cryptoman
osmo14amd

•

7/2/2023

Would we be able to create something different?

What if we could get to a situation where we know the APR of OSMO based on the inflation (that is currently fixed).

Assume we get a 10% APR based on inflation. What if we set that as a fixed APR, regardless where it is coming from?

If ProtoRev, taker fee and such yield the 10% APR, then no new OSMO will be minted.

If ProtoRev, taker fee and such yield a 5% APR, then another 5% APR will be created by minting new OSMO

If ProtoRev, taker fee and such yield 12% APR, then we are lucky (without minting new OSMO)

The 1 billion is not sacred for me, if we would get to a point where protocol revenue is already delivering a healthy APR then inflation can stop imo.

1 Like
5

So…with there soon to be at 94 whitelisted tx fee tokens, which I believe should be narrowed down as there isn’t any reason to accept tokens that can’t even be used on their native chains to pay for the transaction to bridge them over to Osmosis, but I digress…rather than burning all the OSMO, should perhaps some amount, 20% for example, be held back and serve as a “pool” in which collected non-OSMO tx fees tokens can be swapped for OSMO to avoid swap fees and as a “pool” to convert certain taker fee collected tokens to OSMO to distribute to stakers so as to avoid sending people dust and avoid having to pass a separate Community Pool OSMO spend proposal.

6

If we have a pool that is only accessible to internal Osmosis systems that is fee-free, the paired liquidity would have to be held back to cater for this too, and isn’t used by any of the other chain users. The better option might be to allow Osmosis to use liquidity without a swap fee if this becomes an issue. Or, for fees, overcharge for fees in a non-native asset to account for the swap fee or variation in value before the epoch conversion.

7

With @RoboMcGobo withdrawing the distribution proposal (Proposal: Disposition of ProtoRev Collected Revenues - Distribution - #15 by Common) and with most discussions across platforms having stalled, I am planning to move this to chain on the 24th July.

1 Like
8

One questing which keeps bugging me is whether we should send the non-OSMO to the CP and let the CP grow… or whether it should be some kind of swap where we send non-OSMO in, get some OSMO out and burn that as well. CP diversification without growing the pool.

1 Like
9

That was the original burn prop (519) which got rejected. While it is a heavier burn the feedback I had was that it was overcomplicated and unnecessary when a burn is already in place.
Especially if we may eventually need to cap that offset burn to prevent the OSMO in the community pool running out in future.

10

I think I made things confusing by using the word “pool”. What I was really imagining was it being a separate Community Pool account so it would be like swapping out Community Pool OSMO if that makes any sense.

If already collected ProtoRev OSMO revenue was at least held back and not burned and held specifically to convert tx fees paid in native IBC stablecoins to OSMO for distribution to stakers till the OSMO is depleted, it would be away for the Community Pool to build up a rather decent stablecoin reserve.

I am still not convinced that burning OSMO from ProtoRev is the best use of the OSMO and believe the most equitable way to burn OSMO would be from OSMO raised from a community tax. Nevertheless, I would like to see some safeguards put into place. Off the top of my head, some safeguards include:

  • The max amount of ProtoRev OSMO revenue per day cannot exceed the amount of OSMO the Community Pool receives on a daily basis from inflation.

  • The burning of ProtoRev OSMO revenue must be renewed at least once every year. The proposal to activate a burning program should have a hard sunset date, at which if a proposal is not passed to renew the burning program before the date, it will automatically sunset. This does not preclude the burning program to be modified or cancelled before the sunset date though.

*The burning of ProtoRev OSMO revenue shall halt once X amount of OSMO has been burned.

  • The total amount of OSMO burned from ProtoRev revenue cannot exceed more than X% of _____________ supply. (circulating , floating, total, staked, Community Pool, etc.)

  • If OSMO is overcaptialized and OSMO needs to be burned, match ProtoRev OSMO revenue burned with burning Community Pool OSMO at a 1:X ratio. For example, for every OSMO burned from ProtoRev revenue, 0.1 OSMO from the Community Pool will be burned that shall not exceed 1 million Community Pool OSMO

*While there are multiple sources where community members can keep track of ProtoRev revenue, for accounting and transparency purposes, there should be a burn tracker available and up and running to count the number of OSMO burned before burning starts and be integrated into this forum and/or on the OSL support website.

11

I get what you mean there, but one of the main drivers for this simplified proposal was that feedback indicated that the mechanisms suggested in 519 were too complicated. This sounds even more so.
If we’re not burning the Community pool OSMO then there is no need to limit the amount that protorev burns since it will gather less # OSMO as OSMO gets more scarce in the event of a snowball effect. Not that we would be in danger of running out from the amounts burned though.

Since this will all be modifiable by the gov props changing parameters then it can always be changed rather than indicating forced renewal periods which add even more governance burden.

I’m still not sure what you mean by a community Tax, who is paying this?

12

Sorry, I should clarify that I am basically advocating that Osmosis adopt a community tax on block production and burn OSMO that is raised from that tax.

Was there any feedback on whether a burn cap is something people would want to see?

Capping the amount of OSMO that can be burned to X amount of OSMO or X% of total supply is a rather simply safeguard parameter that would more clearly communicate what the community believe the appropriate supply of OSMO should be and I believe more likely for the burn program to successful as a general rule is that markets tend to react more positively when supplied with more information.

I also feel that a burn cap would be appropriate as I suspect how much OSMO is burned will have an effect on how much OSMO is liquid staked. If we believe there is to be a strong positive relationship between the amount of OSMO burned and amount that is liquid staked (or in other words as the amount of OSMO burned increases so does the amount of OSMO liquid staked), a burn cap could be an effective way to help manage the growth of OSMO being liquid staked.

Also rather than a proposal to burn ProtoRev OSMO, perhaps from a procedural standpoint, it would be better to establish a ‘Burn Program’ and classify ProtoRev OSMO as the first source of OSMO to be burned. Combined with a burn cap on how much OSMO can be burned, it may be a way to better manage future proposals to burn OSMO from other sources.

Just throwing out different ideas I think could reasonably make the program better. =)

13

Hello, before all, thanks for your proposition.

I agree with the majority of your points, but there is something I don’t get.

The actual inflation is incentivizing staking and lping by a dilution, burning these revenues would remove this incentive and even if at long term it would be good for price I don’t think that it is our priority.

We need to enhance the UX in order to make the ecosystem grow, and this come before the price action (which could grow following the ecosystem growth).

Why don’t we provide protocol owned liquidity on osmo paired pools using these revenues ? We could make a periodic proposal to define in which pool and in which proportion we allocate these revenues (like the proposal for incentive adjustment).

To provide liquidity to these pools, we need the secondary (or/and third) token, in order to avoid creating sell pressure on the osmosis token we could swap the non-OSMO token of the protorev revenues to these needed assets.

These lp share shouldn’t be bonded (not affecting the bonding APR for the community) and should belong to the community pool. This way, the Community pool is still owning non-OSMO assets through these lp shares.

The last problem with this idea is that we don’t have an equity between non-OSMO and OSMO token in the protorev revenue. For the remaining funds after lp :
- OSMO tokens are burned
- non-OSMO tokens are sent directly to the community pool

Since the luna crash, the TVL on osmosis in an issue and even with the concentrated liquidity update, some pools still lacking in liquidity (OSMO/NTRN for example). We could solve this problem and some more (diversification and passive earning with swap fees for the community pool).

(sorry for my aproximative english)

EDIT :

My proposition could be a temporary solution until the liquidity isn’t a problem anymore. Your burn proposition is very interesting but i think that it’s too early to think of a deflationnary modele as it’s won’t be the case before some monthes / years.

14

I personally can’t get behind any type of burn mechanism, they are cute but do nothing for the protocol long term, especially if we are still emitting supply like candy. Offsetting inflation doesn’t actual matter bc its an asinine amount, similar to the proposal’s reasoning not to send it to stakers.

We also shouldn’t be treating Community Pool OSMO as a reserve or something that needs to accrue value, those tokens don’t exist, the inflation distribution is no more than a budget.

I propose that we pair all revenue as LPs the way they came in. Ultimately Osmosis needs a lever to start weening off of incentives for price discovery pools, and this will be a start. Creating Osmosis LPs can’t be “too complicated”, make it manual if we have to, but burning OSMO is useless since we can mint it freely.

Imo the only options are POL & staker distribution, burns need to leave the conversation.

3 Likes
15

POL should definitely be a priority once we have a system in place to do this with supercharged liquidity. The non-OSMO from here and the share of taker fees will contribute to this.
The only contentious bit of the ProtoRev seems to be what to do with the OSMO portion.

I’m mostly indifferent to whether this gets distributed or burned, but burn mechanics have been very popular with community requests, and so are potentially worth more for being available than the value of the actual burn.
We have 85 Million OSMO tokens in the community pool right now. While the accumulation has slowed down, we are not short on OSMO to pair with the non-OSMO tokens.

16

“We have 85 Million OSMO tokens in the community pool right now. While the accumulation has slowed down, we are not short on OSMO to pair with the non-OSMO tokens.”

Problem with this logic is that its all newly circulating supply. ProtoRev OSMO is supply that has already been circulating.

17

But if it is going straight into a paired LP there is no sell pressure on returning that non-circulating supply to circulating. Either way is neutral, it just depends on whether the community pool retains more OSMO or it gets burned.

From the conversations I’ve seen on socials OSMO in the community pool is generally regarded as more of a liability rather than an asset at these levels comparable to the available OSMO liquidity.

2 Likes
18

deflationary OSMO is a very good PR. we need this to create a good look on OSMO and buy pressure from the community. the current osmo graph is not appealing. there is no better advertisement than a big green candle. push the prop!

19

The proposal has already been rejected through governance.

Small side note: before OSMO becomes deflationairy the income via ProtoRev should become quite big and is only a dot on the horizon for now.

1 Like
20

Yes - disappointed by this.
Will see how the ratio changes when the permissionless pools come in and potentially work on a protocol liquidity initiative like @trix mentioned as long as it doesn’t need a huge number of guardrails to be sustainable.