WNXM buyback discussion

Governance Discussions
21

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)

2 Likes
22

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?

1 Like
23

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.

3 Likes
24

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?

2 Likes
25

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.

4 Likes
26

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

2 Likes
27

: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?

2 Likes
28

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?

1 Like
29

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.

2 Likes
30

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.

2 Likes
31

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.

1 Like
32

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.

2 Likes
33

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.

1 Like
34

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.

2 Likes
35

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

2 Likes
36

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

2 Likes
37

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

1 Like
38

Tokenomics is far from guaranteed to change. There’s been a reasonable amount of push-back against it. So, I don’t see that it’s a sure-thing at all that tokenomics will change and go to book value in a short time period. Seems likely to me that we need to discuss this a bit more, take comments into consideration and look at what needs to change in the tokenomics proposal before it can even go to vote.

Even if it was voted on, which it isn’t ready to be given push-back, comments etc, it could take 6-12 months to do it perfectly, while also managing resulting V2 rollout, other dev commitments, supporting new syndicates, supporting investments etc.

Plus, there’s a natural market that clearly already exists, so hopefully you can still purchase some. How much? No idea, almost impossible to even guess at a number. But, no harm in trying imo.

3 Likes
39

HI Also, here is an ammended proposal in the same vein as above

Proposal: Buyback and Burn of WNXM tokens up to 95% of BV

Premise:

  1. Buybacks below book value are accretive to all holders of all time preferences. At current levels, each buyback and burn of a wNXM by the mutual results in a near 100% return on invested capital. The benefit of that return goes to the mutual and holders. Returns are 20x higher than simply staking reserve pool ETH for 5-10% APY.
  2. The Mutual has a large excess of assets in the Capital pool. A large quantity will eventually be returned to members via V2 Tokenomics
  3. The proposed Tokenomics will implement a similar approach to a buyback via the pools and continue to operate until exits at book value are possible
  4. The Tokenomics discussion and implementation is expected to take several quarters
  5. Frontrunning the new Tokenomics is expected and the longer time to implementation, the more front running will occur.
  6. A buyback proposal with similar parameters to Tokenomics V2 will allow the mutual to nimbly capture more of the value opportunity than just waiting for the new Tokenomics

Proposal:

A $10M allocation to a buyback pool that will be used to buy and burn wNXM. If the pool declines to less than $2M remaining, an additional onchain vote will be triggered to add an additional $10M to the pool. This will ensure there are checks and balances on the total being spent, but also allow for seamless execution of the buybacks without capital constraints. This process will continue until the full implementation of new tokenomics. If 95% of book value is achieved during this period, the pool will transition to a limit order at 95% of book and remain there until the new tokenomics.

The impact of the buybacks will be targeted to be 15% price appreciation (denominated in ETH) per month, meaning the end of month price should be 15% higher in ETH terms than the beginning of the month price as a result of buyback operations. The rationale of 15% is that it will allow the price to gradually increase to near book approximately in line with the implementation of the new tokenomics – thus allowing reasonable time to maximize the buybacks but also provide opportunities to those willing to exit below book value.

The execution of the buyback will be up to the discretion of the Nexus Mutual Investment Team. That team alone will have the discretion around timing and size of buybacks within the parameters of this proposal. The rationale behind Investment team execution is to allow the flexibility of this team to transact in the open market with the least amount of publicly available information that may be used to frontrun transactions.

The team executing open market operations for this proposal will be prohibited from transacting in wNXM on personal wallets for the duration of this proposal. This is commonly referred to as a “blackout period” and is used to prevent transactions executed with insider information.

Concerns

  1. “This will require 2-3 mos of smart contract work, delaying the implementation of the new tokenomics.”

While this is true and certainly a tradeoff, the net effect of this operation would actually speed up one of the core outcomes of the new tokenomics – appreciation to BV. Additionally, it would do so in a way that allows the best possible outcome for the Mutual via capturing the arbitrage. It also allows a narrative reversal around the Nexus Mutual to happen more rapidly. 2-3 more months about “trapped money” FUD vs 9-12 with waiting.

  1. “This will drain the Capital Pool of resources needed for the new tokenomics implementation”

I believe this is exactly backwards. There is roughly X% of the capital pool that wants to exit. The question is what price will it exit at? With a quick and nimble buyback, that X% can be bought out at lower levels than waiting for Tokenomic, thus saving capital for the capital pool. Additionally, I think a rapid and predictable increase of token value will cause more “fence sitters” to stay, thus reducing the total % of NXM that plans to exit.

  1. “Moving funds out of the capital pool creates risk”

Yes, but my understanding of the tokenomics is that this will have to happen eventually, so in some sense it is a “sunk risk” – the capital pool will be accessed

  1. Why not just use the Maple money and not create all this fuss?”

The economics of implementing this are too good to pass up. This is the single, best investment the mutual can possibly make (100% return instantly). This is a one-time opportunity that will close sooner or later. We should be all in on turning this negative (trapped liquidity) into a huge positive for all holders. While this arbitrage exists, there really isn’t an alternative use of funds that comes close and therefore a rational manager should execute to the fullest extent possible.

2 Likes
40

What pushback are you talking about man? I am unsure what your goal is by sending this post that aims to dilute all the productive discussions we’ve had over the past few weeks re tokenomics.

Based on publicly available information, we know that both Hugh and Blockchain Capital are FOR progressing the mutual forward away from this 2 year long deadlock and it rightly comes at an opportune time with the new v2 launch.

If you’re injecting FUD because you want to minimise front running then I’ve got some really bad news in the coming weeks. What would you expect will happen when the pulse check vote is put up and voted on? wNXM simply rerates higher. What if it is voted down? Well we remain in this 2 year long stalemate with little to no progress made.

It’s understandable that you may want to save a few 100k from front runners but also ironic given the loss of thousands of ETH to the lending pool defaults

1 Like