WNXM buyback discussion

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.


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


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


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

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.


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.


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

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.


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

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


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

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.


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


  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


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.


  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.


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

I don’t know how else to characterize tens of thousands of words written in Discord from members regarding their concerns about deviating away from the bonding curve model, towards what Rei suggested.

It might pass, I haven’t spoken to every token holder, nobody has. But my point is that there has been pushback against the proposal, so it’s not like the vote is a lock.

1 Like

That’s fair and those are valid concerns.

Will be a nervy vote but hoping we move forward. Thanks.

1 Like

Hi All,

Wanted to add some color to this discussion and inform the DAO of a tool that’s tailor-made to help execute these buybacks: TWAMM.


TWAMM is a concept introduced by Paradigm in July 2021.

It works by breaking long-term orders into infinitely many infinitely small pieces and executing them against an embedded constant-product AMM smoothly over time.

Some interesting use cases for TWAMMs include treasury diversification, whale liquidations, peg maintenance, onboarding collateral, etc.

We have been researching and developing TWAMMs since November 2021 and have posted monthly blog/tweet threads updates of our findings and progress.

For further details and reading, please see our documentation page here: https://docs.cronfi.com/

Product Design & Incentives

  • AMM: we built our TWAMM as a custom pool on top of Balancer V2 Vaults given the security, liquidity, flexibility, and gas advantages of leveraging Balancer. Additionally, Balancer has become a Schelling point for protocols leveraging their AMM, thus creating network effects & composability advantages.
  • The Mutual: as a long-term trader (Nexus Mutual), you only have to pay gas for starting, canceling, or withdrawing proceeds from your order. All the other sub-orders of the DCA are done virtually and cost the mutual no gas fees. Virtual orders are only written on-chain when the next user interacts with the protocol (generally an arbitrageur).
  • Arbitrageurs: as seen on other AMMs like Uniswap, arbitrageurs are essential to keep the price of the assets in line with external venues. Arbitrageurs are critical for TWAMMs because trade sizes are significantly larger and last for multiple blocks. Therefore we partnered with dedicated arbitrageurs (Rook, BloXRoute) to ensure pools are arbitraged frequently thus giving the mutual a smooth fill.
  • Liquidity: the final piece of the puzzle is the liquidity needed to actually execute the trade. Because we use dedicated arbitrage (PFoF) system, we can collect and pass a share of the MEV back to LPs. Additionally, we reinvest the MEV rewards into the pool thus adding liquidity to the pool and increasing LP returns in pool tokens.


  • Automatically DCA over 1000’s of intervals gas-free: the Mutual would only pay gas for starting and ending orders, arbitrageurs pay for placing suborders on-chain
  • MEV resistant: swap executed per block is very small and front running/sandwiching suborders aren’t economically valuable.
  • Fully on-chain: zero dependencies on off-chain services, oracles, compute etc.
  • Minimal dev work: easy-to-use periphery contract to execute long-term swap
  • Low fees: ETH/WNXM is a volatile pair and long-term swappers pay a one-time 0.3% fee
  • Flexible: issue, change, and cancel orders with ease. Example new order: sell 10_000 ETH for WNXM in 100_000 blocks
  • Full control of order and assets: non-custodial, cancellable, and withdraw proceeds at anytime
  • Withdraw multiple times: users can withdraw once at the end, or every set number of blocks – they just pay gas fees


  • Smart contract:
    • Audit: we’ve completed an audit by SpearbitDAO with 0 critical issues.
    • Hack Risks: built on Balancer V2 Vaults which have been battle-tested for 2+ years.
    • Bricked Pools: we’ve done extensive research and mitigations for gas, order DDoS, numerical underflows, incorrect TWAMM parameters etc.
    • Loss of Funds: open-source code, audited, non-custodial, users in full control of funds, trade happens over multiple blocks and it can be canceled at any time by the user.
    • Malicious Pool Admin: all pool administrators can do is pause the pool and set fees (max 1%) at which point the mutual can cancel and withdraw their funds
  • Lack of Arbitrage: we have teamed up with Rook and BloXroute to provide dedicated arbitrage service. On the off chance neither service arbitrages the pool, the open market will arbitrage the pool.
  • Poor Execution: orders are cancellable at any time i.e if the price escapes preferred bounds restart the order at another time. Also, DCA is generally a better strategy than spot purchase for large orders.
  • MEV/Sandwich Attacks: orders are broken into small pieces and thus the benefit of front/back running orders is minimal – see the Paradigm paper for further details.

Information Leakage

From other posts, this has been an issue for the past buybacks conducted by the mutual especially given an illiquid pair like ETH/WNXM. However, given the visibility of the governance proposal and on-chain execution, a tool that allows you to cleanly spread execution over a long time horizon will be the best way to mitigate concerns.

  • How TWAMM orders can address this issue: https://www.paradigm.xyz/2021/07/twamm#information-leakage
  • As @Dopeee has mentioned earlier, the issue with front running isn’t too much of a concern as the trade will be DCA executed over 6 months. Since the mutual won’t have to time the market, any front-runner would have to buy/hold the assets and associated risks with that trade. Additionally, TWAMM orders can be canceled at any time and restarted trivially.

How TWAMMs stack up

Below is an example of how a TWAMM order would execute with roughly 1.2% slippage:

Swap Amount:  $12M (8000 ETH @ $1500)
Time Period:  180 days (6 months)
Num Orders:   1080 order intervals: 1 order every 4 hrs
Sub Orders:   $11,111 ~= $12M / 1080
Avg Swap Gas: $0 // nexus mutual doesn't pay gas fees for sub-orders
Slippage:     1% -$111 // higher end of potential slippage if dedicated arbs don't act


Slippage:   - $120k // does not account for potential price movements up/down, a crude estimate

Gas fees:   - $200 // gas paid to start & withdraw order

Swap Fees:  - $24k // pool long term swap fees 0.3%

WNXM Return:   $11.856M
Net Cost:     -1.2%

Here are the alternatives and how they stack up against TWAMM. Note this isn’t a comprehensive list, but a short summary.

  • Market Order: Cowswap 03/10/23 -72%, roughly $3,247,851

  • Limit Order: No guarantee on execution!

  • Manual DCA:

    • Pros: can execute it today

    • Cons: need to write a smart contract or fat finger mistakes, fees for each sub-order, gas costs of sub-orders, limited # of sub-orders

    • 6 month Daily DCA of 44.44 ETH, Slippage loss: 180 days * ~$2589 = -$466,020 or -3.88% slippage (does not account for gas costs)

  • Gnosis Auction:

    • Pros: well-tested technology
    • Cons: price discovery, reliant on well-funded keepers, minimum buy lots, price upside capped, infrastructure overhead, limited timeframe, poor execution vs DCA over long periods.
  • DEX/Aggregators:

    • Pros: complete trade in a single block
    • Cons: slippage, MEV attack vectors
  • OTC:

    • Pros: limit orders and other novel trade execution algorithms
    • Cons: off-chain, opaque, high fees, custodial, KYC, regulations, etc

Thanks for initiation of the buyback discussion!

I would like to keep this conversation going as this is a great way to build value to the NXM token (through profits of buying something materially below backing) and also materially change the environment where there are unhappy holders looking at value below the net asst value.

This can be a great strategy to potentially affect price action running up before the new tokenomics/version release and also post release as well. With a number of RFV related actions in other protocols such as Aragon - converging the the price of wNXM with NXM (and this is at a profit) can also help keep such sentiment at bay.

Brief on Methodology:
Buybacks can be executed easily through a number of methods - both on DeFi and CeFi as I think trading firms are more than happy to assist on this. In the past, I have been part of the treasury team at Wonderland a while ago, and executed millions of dollars of buybacks using a mix of methods.