ProtoRev, Revisited

[Winfred]

Do we have to decide on only one use of the OSMO bit of Protorev? Coz in my head, it makes sense to have some flexibilty.

For example, during a bull run, it would make sense to burn the OSMO for the narratives which could create excitement, and via feedback loops, potentially onboard tons of people to Osmosis.

Post bull run it seems to me that this option:

@JohnnyWyles

ProtoRev could be used to offset traders slippage losses - May align traders with Osmosis more, but also may have zero impact as they may just sell the OSMO.

would also be awesome. Burning no longer makes sense at this stage since demand will be decreasing anyways and would undo the effects of burning. Using OSMO to reward traders then becomes a user retention strategy at a time when retention really matters.

Also really love this idea:

@Automatic Staking of Osmosis Incentive Rewards

This proposal would approve a change to Osmosis tokenomics during a future software upgrade that automatically stakes internal OSMO liquidity rewards to a user’s preferred validator set.

[LeonoorsCryptoman]

I love this nuance.

In a bull you indeed don’t need to stimulate people to buy the asset, since then a good story and attraction matters.

During bear markets you need to stimulate people to not sell their assets. Creating some additional rewards can be a good tool, as long as it is combined with the automated restaking (so we don’t give liquid assets which can be sold after all).

[Tricky]

@JohnnyWyles

but mostly the demand is the speculation that there is a fixed maximum supply and this is an increasingly scarce asset. This is entirely the perception of value again rather than actual value.

I’m of the opinion that burning only has decent economic pressure itself in the long term, and the short term is mostly a narrative event.

This is why im hesitant to believe that a burn will lead to an increase in price vs reinvesting these tokens in a way that can bring more value to Osmosis. We won’t really be able to judge the value add by this burn until a while down the road, so taking incremental steps here seems the most responsible. I agree with @Winfred, whichever route we go we need to allow for flexibility.

@JohnnyWyles

ProtoRev could be used to offset traders slippage losses - May align traders with Osmosis more, but also may have zero impact as they may just sell the OSMO.

I don’t think I would support refunds to traders, but maybe using a portion of the funds as trading inventives if we are so sure we are not doing enough for traders (which I think Osmosis has already done a lot to put traders 1st). Forcing these funds to be staked if they are given is ideal, but how will that be delegated and who chooses the validator?

WHAT IF - We use ProtoRev to fund spends on Osmosis? This would encourage us to be more financially responsible, and only use the CP as a “savings” to supplement larger spends when needed. In this way, we also do not add to the real circulating supply as much with each spend.

In general, I think we need more discussion such as a twitter space hosted by the team to get this topic more on top of mind. Considering there’s no hard data that says this will benefit Osmosis long term, we should look to repurpose these funds to drive value and only go forward with any burning in increments.

[LeonoorsCryptoman]

The

@Tricky

WHAT IF - We use ProtoRev to fund spends on Osmosis? This would encourage us to be more financially responsible, and only use the CP as a “savings” to supplement larger spends when needed. In this way, we also do not add to the real circulating supply as much with each spend.

This part really makes me wonder though. I don’t think people will treat requests differently based on the source of the funds. Whether it be ProtoRev or CP, as long as people don’t look at the requests just like it would be funded by themselves it won’t matter where the funds come from. As long as people don’t consider what they would do if it would have been their own money we won’t win that battle. So I would be against saving it for funding stuff, because we already have enough of that (especially in combination with the OGP which also does exactly that).

How we spend the revenue should always be an automated thing. No interpretation should be allowed for that, which is where the split for non-OSMO funds to the CP for diversification and a burn for the OSMO funds would / could work, because the split is so clear.

[in3s.com]

I’m all for burning, but let’s make it a proper burn by annihilating the OSMO, not just sending it to a null address. What’s the difference? OSMO sent to a null address is still tallied by block explorers and coingecko and all sorts of other tools, so when new investors do their analysis on OSMO they won’t see the true circulating supply.

[JohnnyWyles]

The null address is going to be excluded from the general supply queries (Mintscan), but it makes tracking the burned quantities much easier.
Explorers rely on the supply endpoints rather than doing any other tallying so this will be reflected across them.

[in3s.com]

That’s sort of good news, but sites that non-Cosmonauts use, eg https://cryptoquant.com/, aren’t aware of the null address nuance. We want non-Cosmonauts to invest in OSMO, so them seeing a bigger circulating supply than exists is not good.

Plus, even https://analytics.smartstake.io/osmosis/stats/addresses, a great contributor to the Cosmos ecosystem, needs manual intervention in order to flag the null address as special. Search for the null address on that page. You’ll see that it appears as just another account (ranked 120 as of the time of writing). ie, It appears to be a whale with no staked OSMO that can dump OSMO at any instant.

What’s so difficult about properly burning? It literally takes less than 100 lines of code to implement.

[LeonoorsCryptoman]

Plus that for example Chihuahua already has the code for it, which we can also copy-pasta.

I would indeed be in favor of a real burn as well, since it just removes any reliance on manual interfering (which is never good and leaves to much room for error down the line).