WNXM buyback discussion

New tokenomics will not be for 6+ months. This will get executed way before that, a bid like this should aim to get finalized within 1-month. Sizing needs to reflect this as time is a component in how well this approach works.

If your logic is that new tokenomics solve this anyway, then the concern about reasonable price for ensuring DAO longterm runway is moot, because it will solve itself. So, the sole focus of a buyback in the interim should be maximizing BV. (also, agree it’s too late to fix this for the next 6-month budget)

1 Like

I’m not particularly against it but why does it have to be within 1-month?

isn’t it good enough to wait for v2 & partial claims → then do the limit buy/buyback → then focus on implementing tokenomics?

I wasn’t clear. I’m saying that as long as the buy is a reasonable size, it should get filled entirely within 1-month. Meanwhile, tokenomics is 6-months away.

So once V2 is live, we can do this buyback and have it done within 1-month. I was explaining this to show why there is plenty of time to do this (multiple times perhaps) before the new tokenomics would go live.

To be clear, I’m not suggesting this needs to finalized 1-month from today.

2 Likes

This makes a lot of sense. What are the next steps - can we think through the parameters (e.g. how much ETH should be used for this and at what price) and then put it to a snapshot vote?

1 Like

If people are comfortable with the approach I described above of just a fat bid into the book, and we agree to never increase it, I think the only important parameters are the amount and the price.

Then, we need to agree on how this is technically done.

We will have ETH in the Enzyme pool following withdrawal from Maple. I’d suggest we just do it there, using Cowswap or whatever protocols they have integrated.

In terms of parameters, I’d avoid trying to overcomplicate this too much. @Gauthier had some metrics previously on liquidity across all books, we could use that to get a guide for how much we think we can deploy at a certain price, over a period.

Maybe we can look at how effective doing 5% of the capital pool and a 20% premium to current price, with a maximum execution period of 3-months would be.

Pulled those numbers out of thin air, but they “feel” in the right ballpark and then we can optimize from there to find the right true parameters. Would caution against trying to overoptimize them too much though, as it’s near impossible to know what true liquidity will be when such a big bid is put into the book.

Doing something as simple as randomly breaking the bid up into smaller chunks, deployed at random over a period will likely reduce slippage meaningfully. Beyond that, it’s hard to optimize with our limitations around technically doing the order.

3 Likes

great idea @Dopeee! would agree to something like 5% of the capital pool and up to a 20% premium to current price, with a maximum execution period of 3-6 months

1 Like

:point_up_2:This is the best course of action.

About the buyback, I haven’t read fully all of the other proposed ways to do it, but to avoid front-running you can just set a reverse dutch auction: 1) Set up a smart contract, fund it with x kETH, set a deadline of one week or something.
2) define a max price that the mutual is willing to buy back for, e. g. book value
3) let people send their nxm or wnxm tokens, with an UI in which they say which minimum price they will accept
4) Two options here: a) take all offers starting with the lowest accepted price until the eth pool is exhausted, or b) do some math to calculate the maximum amount of nxm/wnxm that can be bought, buy paying the same price for all nxm/wnxm tokens, regardless of the minimum price accepted by the holders.
5) pooled wnxm/nxm tokens that aren’t bought, are returned to the addresses they were sent from.

I think 4.b) is better because it encourages users to submit lower offers knowing that they may get better prices anyway.

In this way one pro is that also nxm holders can participate. Also doesn’t need to reduce wnxm liquidity in dexes and cexes.

And how could you front run this if you don’t know what the final price is going to be?

1 Like

That’s a smart and creative approach! Quite convincing.

Thank you for laying out the steps too.

However this part here has me a bit worried regarding the possibility of implementation:

Afraid this would be too large a dev effort for a one-off

Or have you seen it implemented somewhere with audited smart contracts the mutual could get inspiration from?

Doesn’t have to be one off. You can add a relatively low amount of ETH, and repeat this process several times.

But also maybe there are off-the-shelf smart contracts built by other teams that we could use, I don’t know. If they exist they definitely would save time and effort.

I think I’ve heard other protocols releasing their tokens this way (only with a dutch auction, starting with a high price and going down, here it would be needed a reverse dutch auction), but I can’t remember which ones though.

1 Like

This is a very complex approach and it’s not clear to me how this is better than doing the same thing in a Uniswap pool. Essentially you’re just putting in a bid at a set price and will pay up to that.

This doesn’t not prevent frontrunning in any way. Frontrunning in this context is the inflation of wnxm price above the starting market price, because people know a buyback will happen and they can resell to us later.

If we agree to buy at book value and the wnxm price just jumps up to book value, all of that spread is being captured by the party doing the frontrun. Less of it is captured by the mutual.

To limit frontrunning will maximize value for the mutual. To do that, we need to buy at the true market price before a buyback is discussed. The only way I see to do that is to just set the price you’re willing to pay as the market value before buyback discussions happen and then wait to get filled.

If you pay above this starting value but below book value you still add value, but most of it will be captured by frontrunning parties not by the mutual. Whereas if we minimize the value capture by those parties we maximize it for the mutual.

1 Like

One of the biggest advantages of the reverse dutch auction is that you can execute a significantly higher volume than what you could do in other ways. For example if the token would be trading at 0.011 as it is now, and you offer a 5kETH reverse dutch auction to buy tokens at a value of up to 0.022, you may end up buying 5kETH worth of tokens at a value of 0.016. It is true that announcing such an auction would maybe increase the price of the token to 0.012 or 0.013, but probably not much more since buying tokens in the market to sell them in the auction means taking the risk of not selling them, and ending up with tokens that you don’t want.

And for comparison purposes, if you make a purchase of 5kETH in Uniswap right now, you’d be getting a price of 0.04331, since the liquidity is very low. There’s also the 1% comission for the liquidity provider.

Agreed, I was supportive of a reverse dutch previously. My main concern since then has become the risk of collusion, where parties just wait until the price hits the maximum before selling. My argument against this previously was that people will just automate this and so bots will do most of the selling, giving us a reasonable execution. But this won’t be the case since you have to pre-announce the conditions for the auction and so as you said, you just get a wNXM run up from humans frontrunning it.

I don’t think that frontrun would be as limited as you say for exactly what you mentioned after, which is that liquidity is very low. If we do a 5k ETH buyback, you rocket the price to 0.04331 according to you, and it doesn’t make sense to do less than 5k ETH buyback total. So, we know that humans frontrunning this will easily take it to the max of the reverse dutch auction price very very quickly. I don’t find the argument that they won’t do this because of risk of not being able to sell very compelling, as the amount we would want to buy in a reverse dutch auction will be much much more than the amount bought on the open market would take to move the price instantly to the max price of that auction.

That’s why I’m proposing now that we just set a max price, and sit on the bid. You need a lot of time to execute in size, because of such poor liquidity. So the mechanism likely needs to be extended to buy over a longer period, as with my latest suggestion.

1 Like

To give some context as to what the frontrunning was last time and how that appears to have impacted the buyback. Discussions around it started seriously in early October. The main forum post driving it forward went live on November 4th 2021, and the vote was finalized November 17th 2021.

The low price of ETH / wNXM was on November 2nd 2021, when the price was 0.0112. Following discussion, the price climbs significantly. The final average execution price seems to be 0.018. The book value, roughly, for the period is about 0.024. So, we captured about half of the gap between wNXM market price at the start, we can consider this true market price, and book value. The other half is captured by frontrunners taking the price from 0.0112 to our average execution of 0.018.

50% frontrun is not ideal. I picked a number basically out of thin air, which was providing the market a 20% premium to true market value and buying there. If we could execute the same volume at that price, it’s obviously superior to buying at a 50% premium as happened last time.

Right now we’re at 0.010 ETH / wNXM. Book value is about 0.022. Meaning the spread right now to book is pretty similar to what is was prior to our last buyback. However, if we look at when this newest buyback discussion starting happen, late December, we see that the ETH / wNXM price has nearly doubled since mid January. Nearly nothing public happened in that period other than the buyback discussion, so it’s fairly reasonable to assume that a good chunk of the run up in the last few weeks has been driven as a result of trying to get ahead of a buyback already.

If we go with an approach of putting a bid in at a 20% premium to price, we can’t just use the price on the proposal date because this just allows further frontrunning during the proposal period. We would need to use some sort of average. The 30d trailing average VWAP pricing right now is roughly ~0.009 ETH / wNXM, a 20% premium to that would be 0.0108, which is almost the current price at the time of writing.

About 32 ETH of volume goes through Uni v3 on this pool each day. It’s hard to know how much volume we could get at this price, given a lot allegedly goes through Binance and OKX. Given the ±2% depth is very weak, I’d think that if a lot of extra liquidity appeared on DEXs you’d see quite a lot more volume driven through the DEX, as even after the 1% V3 fee you’d get less slippage on the DEX than CEX.

If we assume 100 ETH volume per day, if we wanted to execute an 8k ETH buyback as we did prior, we’d be looking at 80 days. This is an overly simplistic example, and likely not realistic, but it just gives some context. 80 days isn’t overly long and fairly reasonable to me.

I’m quite confident that much of the run in wNXM price recently is as a result of the discussion around buybacks. The market price only 4-weeks ago was half of what it is today, and buyers at that price would realize a 100% gain by selling to us at the price I just suggested.

I’m going to suggest we just bid at this current price and sit on it, refusing to increase it. It’s a very fair price given a 30-day moving average, and it’s the current market price as well.

It’s not clear to me whether we should just throw an 8k bid into the DEX at this price, or if it’s better to split it up into multiple randomized orders. If we do a big wall, my fear is that algorithmic traders will react instantly and move their offers above it. But if we randomize it into smaller bids over time, you don’t create the extra depth which reduce slippage for traders and should drive more volume into DEX rather than CEX where it is now.

It’s fairly hard to actually quantify this because you’re trying to guess how other parties will react. My instinct here is that if we’re bidding above the market price, you want to break it up into randomized chunks. If you’re bidding at the current price today, then I think you want to throw up a massive wall to create depth and try to drive greater volumes, so that we can execute more quickly.

I don’t see why we should offer any premium above this price right now. It’s far above the trailing 30 day average, it’s also the market price. That’s what we should be buying at.

Parameters for proposal:

Enter a bid for 6-months
Price = 0.0110
Quantity = 8,000 ETH
Price will NOT go up, under any circumstance
Bid will only be removed or moved down, if approved by the community
Executed through Enzyme, using their team to execute on DEX.
Enzyme team to receive a reasonable fee for execution
Gas fees and other costs to be paid by our side, not Enzyme. Should be marginal

If the market price is LOWER following the vote passing, we should set at that new market price. If it’s higher, we just use the value of 0.0110.

Funds to do this should come from the expected Maple withdrawal, which will end up in this Enzyme vault anyways. As funds drip in, they should be used incrementally according to the above parameters.

I don’t believe any significant dev work will be required here.

There are two main options:

  1. If it’s possible, Enzyme vault should become a member, swap from wNXM to NXM, then call the NXM burn function and burn the tokens for us.
  2. If it’s not possible, we would need to allow the Nexus Mutual capital pool to hold wNXM, then withdraw the funds there, do the swap and burn the NXM. This option becomes more complex and certainly would require some dev work it seems.

The first option should be possible, if we can whitelist the address for the Enzyme vault in our system. Ideally, we can just add the address. If not, Enzyme vault would need to call the contract to become a member. Then, call the contract to swap from wNXM → NXM. Then, call the NXM token contract to burn the tokens. I believe all of this is possible, and would not require development work on our side.

In terms of the oracle, the risk here is that the wNXM price is manipulated in the period between us buying it and completing the burn. This would throw off our smart contracts by making us think we have more funds than we do. AFAIK, the vault automatically uses the 30d TWAP price, and so it’s a little bit harder to manipulate, particularly as there aren’t any large markets for borrowing wNXM right now. Hopefully, this risk is acceptable given that it should only be for a relatively short period. If it’s simple for us to just turn this oracle off and pull no value from the vault, that’s also a nice option. But given how small the capital in the vault will be, the price would need to be manipulated insanely high to make a difference big enough to impact our contracts.

I have some additional context on this scenario.

  1. We believe that we will receive a large amount of wETH back into the Enzyme vault shortly. Not counting the chickens until they hatch, but optimistic here.

  2. Enzyme is unwilling to do the swap on our behalf. However, they can add a wallet address to act as a manger. I would propose the community multisig. They will then sign a message to buy the wNXM as discussed. Then, we will send the wNXM to the community fund multisig. I believe it’s already a member, so it can swap the wNXM to NXM. Then, if we decide, they can call the NXM burn function to destroy those tokens. My suggestion is this vote should only be for the buyback, with a separate vote after the fact to decide whether to burn the tokens or use in some other manner. I know there’s some parties who prefer not to burn, but would buyback, so I don’t want to reduce the likelihood of a buyback vote passing by introducing the component of “what to do next”. None of these steps require any calls from our smart contracts, which is nice.

@Hugh or @rox will be necessary to give some context on to whether this is an acceptable technical solution. The main concern I can see would be, what happens to the oracle we’re referencing if we do this, and what is the risk of manipulation of wNXM price to throw our smart contract internal asset value off.

is there anything else we need to do or can we move this to snapshot?

Thanks for this @Dopeee, you raise good points, particularly on minimizing front running to maximize the benefit to the mutual

I was wondering… if the buy back price is fixed as a massive bid at the current market price (0.01 ETH), and assuming that the tokenomics revamp in it’s current form as proposed by Rei will be implemented sometime this year (I know they are separate topics, but they do intertwine in this case), won’t most wait for the racheting mechanism to get close towards the book value before redeeming? Particularly given that there is another 1x upside if BV is agreed as 0.02 ETH. Naturally, there is time value to capital so I do not doubt that there would be members willing to ‘redeem’ at the current market value even if still at a massive discount to BV.

I might be missing the plot here, but how would a buy back fixed at the current market price, work, when faced with the upcoming tokenomics revamp (which effectively is another form of ‘buyback’ at BV) as a backdrop?

If anything, once a plan is set for the tokenomics revamp, one would expect wNXM to move closer to BV, and thus the mutual would lose the opportunity to buy back at the current market price

1 Like

Hi All, I’m a longtime member of mutual, but newly registered on the forum. I wanted to suggest that outsourcing buyback to another project, and doing it in a streaming/continuous way over many months should also be considered. I’m also a contributor to a Ricochet.exchange project, and there are operational contracts (Currently on Polygon, but shortly on mainnet) that can be used. They could deploy something custom for Nexus which is front-running proof, and over a long time would be executed, as long as funds are streamed in constantly. Interested to hear your thoughts