How much is a good amount to buyback?
Should a buyback be performed privately before publicly announcing to avoid MEV or front-running?
Currently we can only buy back around $500k on uniswap and binance which will move the price around 10%…
If we want to buy $1m it will move it around 30% (due to low liquidity on CEXs)…
Maybe it’s better to buy 10% in one go and then buy more in small bursts?
Reasons for buyback are:
The price is often 75% from spot value…
If the MCR changes we could use it to convert back to ETH…
or to sell it back to customers at a later date at a higher price…
Definitely in favor of more buybacks, at this drastic discount to book value they are a no-brainer to add value to the mutual, buying $1 for $0.3 is an opportunity that will pass and that we need to close regardless to get the mutual back on track for V2 imo.
The way to do it imo
make the proposal for specific range of price / discount in eth: for example between 0.005-0.015 eth per wnxm (given book at ~0.022 range would be at significant discount)
execute via trustless, and gasless https://swap.cow.fi/ limit buy order in weth… and thus mev-protected, and do staged buys starting with more at low price points… eg. majority between 0.005-0.01… and smaller orders towards 0.01-0.015… at random price intervals → this would automatically enable cex’es to slightly arbitrage against it but avoid having to go with centralized intermediaries to execute
use max 5% of the capital pool as a starting point (eg. ~7,25k ETH = ~$8,7m buyback at todays prices would yield us at 0.008 eth per wnxm execution a ~13k ETH = ~ $15,6m net gain for the mutual)
those wnxm should ideally be sold back OTC against ETH without discount to book, or partially burned at a later point, but could partially also be used staged over 4+ years for high roi marketing and growing the mutual (1$ of expense leading to much more than 1$ of gain for mutual)
I’m against using any funds for buybacks in advance of the new tokenomics, which in a lot of ways has buybacks built in to it on an ongoing basis.
From my perspective we have a certain amount of budget for buybacks, and if we use that budget in advance of the new tokenomics then we have less to use later. I believe the best outcome for members will be using as much of this budget as possible in tokenomics rather than one-off uses before hand.
I think it’s best to use more later as the new tokenomics will be more effective the bigger the budget it has, and the new tokenomics should optimise prices better (using dutch auction techniques) as well as be more sustained/ongoing rather than one-off in nature.
Also, a big negative, which we’ve unfortunately learnt several times from past experience, is that any additional work will distract the dev team from shipping the big upgrades, Nexus V2 and Tokenomics.
It’s better to have a permanent built in solution sooner than duplicate work.
I think opposition to buybacks back in January last year was mistaken.
While I’m not entirely convinced by the current argument against buybacks, I am more sympathetic given we have an alternative being proposed to address the situation which wasn’t the case last time.
However timing is an important factor in deciding how to judge a buyback now vs reserving more funds for the new tokenonmics at a future date. I appreciate we cant expect this to be forecast perfectly, but it would be a big help if we can firm up how the timelines are currently looking?
Assuming the audit goes well, when can we expect v2 to be implemented?
Assuming coding up and implementing the revised tokenomics is the first priority after delivering v2, how long do we currently expect that will take?
Agree, without a timeline on new tokenomics it could come Q4 2023, or sometime 24 for what its worth.,. and there are also windows of opportunity for buying back… what i’d support is a concrete a small buyback for taking advantage of massive discount… which i think the new tokenomics wouldnt be able to (as they’d become priced in, people would buy in expectation of how the tokenomics would work… and thus less value would accrue to the mutual than with a standard small buyback in advance)
From dev perspective, making a smart contract call from the nexusmutual smart contract to community fund shouldnt take a good dev more than a few minutes or hours at most…
At the end its really about making sure the mutual buys back at as low of a price as possible… + closes the discount altogether with new tokenomics. I’d bet you that we wouldnt be able to take $wnxm off the market at 0.005-0.008 eth per wnxm, but rather higher prices… so there’s a big opportunity cost not to do a targeted buyback with a small % amount of the total capital pool at massive discounts…
We’re looking to provide more clarity on timing over the coming weeks, but here is what I can share at the moment.
V2 audit has come back fine, we’re making the minor changes required on the smart contracts and are also working through details on migration and UI build (main outstanding piece is staking UI). We’re fully focused on shipping v2 asap. I don’t want any distractions here. We really want partial claims live for FTX, so that’s what we’re working towards.
Tokenomics - given the amount of research work already conducted and my (admittedly high level) understanding of the implementation details required, this is a decent sized project but there is nothing worrying. eg large outstanding research problem to solve. Therefore I’d be quite disappointed if we can’t release in 2023.
From dev perspective, making a smart contract call from the nexusmutual smart contract to community fund shouldnt take a good dev more than a few minutes or hours at most…
While I’d love for this to be the case it isn’t correct at all. It requires a smart contract upgrade, which requires development, testing, audit, governance action, coordination and implementation.
fair makes sense, imo if that buyback yields us $5-15m it would be worth spending $15-40k extra dev resources on it imo, can also just be outsourced to some great nexus collaborators like bootnode or other dev houses (and should be straightforward to execute given it was done already in the past, it should be extremely minor adjustments to the contract)… this isnt rocket science, every legit solidity dev should be able to do it within days…
on buyback, as an example
use max 5% of the capital pool as a starting point (eg. ~7,25k ETH = ~$8,7m buyback at todays prices would yield us at 0.008 eth per wnxm execution a ~13k ETH = ~ $15,6m net gain for the mutual)
again to re-iterate, would happily bet that we won’t get the same large discount to book with shipped tokenomics upgrade in Q3-Q4 that we would be able to take advantage of right now.
can recommend the book “Outsiders: Eight Unconventional CEOs and Their Radically Rational Blueprint for Success” in this regard, enabling buybacks at radical discounts to book is by far the smartest capital and time allocation decision one could possibly make… prioritising other things is simply foolish if we can increase the mutuals net assets per wnxm by tens of millions through this
Also many holders are loosing faith in nexus given the discount, thus it goes even beyond capital return to the mutual… imo wnxm lingering at this discount for 6months and would be a fairly negative sign and thus should be avoided…
but think easiest is to make this up for the DAO and governance to decide… weighing the pros/cons which i understand and hear you raise legitimate points on prioritisation
But looking at the current numbers and assuming that you can execute at those prices is not realistic. This is true both for passing a vote to do a buyback now, and for Hugh’s suggestion of letting the new tokenomics automate the “buyback”.
As I’m very aware of the new tokenomics model, given that I worked on writing the first draft, it’s designed to capture the arb in an optimal fashion. However, it does not prevent frontrunning entirely. The problem of course is that once people see the vote for the new tokenomics the price should move up, removing the opportunity. The frontrunners capture the bulk of arb instead of the members.
The same is true for passing a vote here to do a buyback.
The best solution here is likely to give some funds to a party to execute over 6-12 months. The extended length of this execution window likely prevents most frontrunning parties because they would be required to hold wNXM and the associated risk for such a long period.
I acknowledge that with a buyback you give up some of your moat. However, I don’t think a 5-10% buyback makes any meaningful impact there. Using 50% of the capital for a buyback does.
Frontrunning will be far worse on the launch of new tokenomics than it would be under the transfer of funds to a party to execute over an extended period.
Frontrunning is going to impact the return on the buyback more than the actual execution details (by an order of magnitude I believe). Which is why you should optimize for reducing frontrunning and not on slippage. Hence, if you agree that capturing the arb is a priority, it should be done before and outside of the new tokenomics.
Totally agreed! Which is why my proposal was explicitly arguing for staged gasless limit orders at low price points over long times (and starting with this earlier rather than later/close to the new tokenomics)… and wnxm liquidity is low enough that $5-8m actually meaningfully move the needle… $1m buy moves the price by 40% for example (ofc a bit less given cex liquidity and people selling)…
Exactly as you say, once the new tokenomics is around the corner the price will certainly be at a higher range than right now (having resolution for reaching book value in sight), which is why i can guarantee you that we would make a way different return for the mutual and its members buying back with say 5% of the capital pool today, and then with decently more under the new tokenomics
Putting all points aside and just focusing on this for a minute : if because of misalocation of dev resources v2 isn’t live before FTX claims start to come in, it will probably lead to a sunk cost of $2-5m for the mutual.
Not sure if I’m taking this the wrong way, but the goal should not be to try and move the price to close the gap. The gap is an opportunity and buying should be done in a way which minimizes price movement.
Yes, closing the gap is helpful in many ways. But the gap can and will be closed. The focus for a buyback should be to minimize slippage and frontrunning, so as to buy as much wNXM as possible, at the lowest price. Then, to burn it.
fair point, def agree that this should be prioritized, but saying that the buyback could still happen with fairly little dev resources and outsourced to someone like https://www.bootnode.dev/ (and given it would return tens of millions to the mutual it would be worth spending 10-30k or whatever it costs realistically)
goal should be foremost to maximize return for mutual and its member, which would be to buy as many pennies on the dollar as possible, for as low as possible…
→ this could be done in the most efficient way as i argue here by passing a proposal like the one i discuss at low price points, that executes over long time horizon and with randomized low gasless-mev protected cowswap limit orders vs relying on centralized execution in brief time period like last time
i’m excited and optimistic about upcoming tokenomics but do think it will easily take til Q3-Q4… hopefully Q2 but prob too optimistic, and would be reflexive for the price in the sense that once its worked out, and governed, the price will close more quickly and thus less return for mutual than if we have say 6 months leading up to that for a buyback between 0.005-0.015 eth per wnxm or something
I wasn’t expecting @Hugh to disagree.
Which is a little worrying .
But will be interesting to see how this Dutch auction system play out…
Personally, I think the pros outweigh the cons…
Pros:
We are getting a 75% discount on any future insurance we might want to buy.
If we was to pool WNXM/ETH on uniswap to try and get some yield then we could buy some cheap uniswap v3 insurance and maybe make a profit
If DAO gets hacked and we go to zero… It’s better to leave the hacker with WNXM rather than ETH… (Kind of like insurance against ourselves)
New tokenomics/Dutch auction should push up the price of WNXM compared to ETH. So why not buy before?
We have twice as much ETH in the treasury compared to the total supply of NXM… So the supply is very limited…
Maybe it can be used to sell back to users in the future at full price…
Cons:
WNXM price could go down further and we look a little silly
Less ETH available for Dutch Auctions…
Wasting dev time (Could this not be done in a way that doesn’t waste time? If someone sends $100k to a trusted source then they could do the trade and give it back in tranches.) Most of the guys holding NXM have gone through KYC anyway… I personally live in a “tax haven” so it wouldn’t be hard for me to do some buybacks. And could prove it by locking my personal WNXM for X amount of time as a ransom for example
I think you need to discuss more detail before putting this to a vote. eg how much ETH, price limits, time frame, who will execute etc
Process should be a) snapshot vote to confirm intent, b) dev work, and then c) full on-chain governance vote
Dev Resource
I know it sounds easy, but this is not a simple transfer out of a multi-sig, it requires a smart contract upgrade. Regardless of how small this is, there are security practices we must follow, so there is a level of overhead here.
Any distraction of dev resources right now, no matter how small, including engaging third parties like bootnode will delay v2 (coordination of resources and releases is non-trivial).
Delaying V2 likely has a direct impact on extra claims due to FTX and partial claim payments. FTX claims are likely to start coming in on the second week of February, so it’s not very far away.
totally agree, happy to draft a concrete and reasonable governance proposal to discuss concretely, and get a temperature check from the broader community as it should be
agree that this should be a prio over the buyback…
appreciate your thoughtfulness, patience and thinking long-term Hugh! excited about the future of nexus
The wNXM/NXM price has been off peg for some time now, and it does hinder the mutual’s growth. We all know there are members who would like to exit but can’t due to the MCR lock, which other cover protocols suffer from as well. wNXM can be used to exit, but it trades at a discount to book value and most aren’t willing to exit at the current wNXM price.
To solve this, the tokenomics working group has been working on a design that will require dev resources that would, at this time, take away from getting V2 out. Right now, V2 and partial claims functionality is paramount, as we’ll not only lose capital that could be used to allow members to exit OR execute a buyback, but we’ll burn more NXM than actual loss.
The objective of the new tokenomics, in my mind, is:
Allow members to exit at or near book value
Close the wNXM/NXM price disparity
Enable the mutual to attract capital, adequately price risk, incentive members who contribute as stakers, pool managers, claims assessors, etc.
Executing a buyback ahead of this reduces the amount of liquidity that can be allocated to the virtual Uniswap pool, which has been outlined in the new tokenomics design, which Rei has provided updates about in the Nexus Mutual Discord.
If a buyback was the direction with the most member support, then the ultimate goal would be to buyback and burn wNXM, so BV is raised for all members. The optimal way is to execute ahead of new tokenomics but do not decide what to do with NXM until after the new tokenomics are implemented. Again, there would need to be a discussion on the liquidity reserved for a buyback compared to the liquidity used to allow members to exit in new tokenomics model.
The priority then, from my perspective, is:
Launch V2: Partial claims will preserve capital that can be used for future buybacks, if that’s the direction members decide to go in
Revisit the buyback proposal and take @Dopeee’s points into account on executing over a longer time frame to capture as much value as possible without the price increasing for the buyback window and then decreasing later after it has been completed.
New tokenomics are finalized, audited, and implemented.
If a buyback proposal were passed, wNXM should be held and no decisions on how to allocate should be done until after new tokenomics launch.
An alternative solution here is to throw a fat order into the LOB.
Using $8 as the current price and a book value of $24 (should think in terms of ETH, not $, but using fiat for ease in this example), there is a discount of 66%. Bidding at $10 would mean capturing a minimum of a 58% discount. You give up some of the discount, in exchange for capping the frontrunning.
This seems like an acceptable solution that would allow us to execute without excessive frontrunning, and in a reasonable timeline.
If people still try to frontrun this and bid the wNXM price up above this, but below book value, we would just ignore this. The key to this solution is that we include this logic into the vote so that there is no possible way that we can increase the bid (you should only move down, in case book value slips). This logic limits frontrunning to X% and causes those that frontrun to likely incur losses. Meanwhile, we patiently wait for the price to return to its previous market value.
One obvious problem with this is if the wNXM price increases but it’s because of something other than frontrunning. This will be hard to gauge and so is not worth considering. Instead, you have to accept this risk where the downside is that we do not execute. Opportunity cost is the true loss here.
The way around much of this risk is to ensure that you execute quite quickly, by giving up a meaningful piece of the pie like in the example above.
You can try and make an argument that you can slide the bid up as you go and perhaps you can execute with less slippage. But the beauty of this is that it’s ultra simple and that because you signal (and stick to it) a price you should reduce frontrunning attempts. Anyways, the key is truly that you have to stick to the bid and don’t increase it, no matter what.
There’s a way to do something like this with Uniswap V3 liquidity, which we could consider, but throwing this into the LOB using Cowswap is probably the simplest approach.
Issue is that eventually new tokenomics get implemented and the pool price increases by x%/day. It will catch up very quickly with the limit price you propose.
Also, this approach tries to maximize BV but doesn’t solve for the exit liquidity at a reasonable price issue. The latter also allows the DAO to considerably decrease the cost of the Hubs since budget is denominated in $ (but maybe it’s already too late for the next round of funding).
.
