Late to this discussion, but wanted to weigh in here.
Based on what we’ve seen so far, I think we’re on track to see ~2M NXM redeemed, which is within the initialBudget amount. One large address has made ~60% of the redemptions so far, and the second largest address has made ~14% of the redemptions.
While there are address among those reading and commenting on this thread that have NXM and plan to redeem it, they have another 24 days to exit during the initial exit period and they can redeem any time after it ends as well. The RAMM is working as designed, and the time for folks to raise concerns about the mechanism design have passed now that members voted to approve and implement the RAMM.
I understand that there are members who want to redeem but do not want to wait for the ratchet to move back to book value after other large holders make redemptions. If that’s the case, I’ve shared below that the fastRatchetSpeedb param is the one you’ll want to focus on.
My assumptions on the wNXM supply are based on unwrapping activity over the last six months, which I’ve shared below. People with wNXM are just going to sell or place limit orders on DEXes, like we’ve already seen addresses doing on-chain.
While I don’t think there’s anything wrong with how the RAMM is working and performing, I am open to a productive discussion with clearly defined values. I’ve shared my thoughts on what parameters folks should focus on and how it impacts the RAMM below.
I’ve also made some assumptions based on comments in the thread to date. If anyone has definite values for the parameters they’d like to see changed, please share those below my comment so we can keep the conversation focused.
My Thoughts
Determining Consensus of Community Members in this Thread
It’s been roughly six (6) days since the RAMM launched and the ratchet first moved near book value, with the ratchet target within 5% of BV on Wednesday (22 November).
We’ve seen 365,805 NXM burned as a result of people exiting, with ~7,207 ETH redeemed through the RAMM as of current data.
Right now, there’s 36,662.05 ETH allocated for the initial exit period, which would allow another 1,690,820 NXM redeem and exit the Mutual at book value (0.021683 ETH per NXM); if members exited at 95% of BV, then a total of 1,779,810.52 NXM would be able to redeem and exit the Mutual. That’s ~26.5% to 27.8% of the current NXM supply redeeming for ETH.
If folks here think we’re going to see the appetite for redemptions exceed that within the next 24 days, then you’re correct, the two points you’d want to focus on are:
- Amount of capital provided for redemptions during initial period
- Speed of deploying liquidity
Amount of capital provided for redemptions during initial period
Members signalled their support for releasing 30% of the capital pool during the initial exit period in this Snapshot signalling vote, which is where the 43,835 ETH value for the initialBudget came from.
All of the comments in the Liquidity Parameters Discussion (Part 1) | How much ETH liquidity do we start with? thread on Question 1 primarily focused on the 30% value.
On this: if these holders wanted to exit, wouldn’t they have unwrapped to NXM by now? I think it’s fair to say there’s wNXM waiting to exit, but if people hold wNXM and aren’t members, they are just going to sell on the market and not redeem through the RAMM. Anyone can look at Uniswap V3 and browse the wNXM limit order history to see what addresses have placed limit orders.
I’m not as convinced ALL wNXM or even 80% of wNXM holders want to exit. However, there are people who have unwrapped wNXM to NXM in the last 180 days, which amounts to 352,008 NXM by filtering the txns with the unwrap function on the Wrapped NXM contract.
Based on your comment above, @Pankookas, are you suggesting an additional 23,665 ETH be allocated to the initialBudget amount?
Again, just trying to parse out where we’re at in this discussion so far, since there’s been quite a bit of back and forth but not much in any suggested figures so far. @ngmi & @Pankookas, I appreciate the context you’ve provided, as it gets the discussion closer to having a potential answer to the first point you’ve posed and commented on.
Speed of deploying liquidity
Based on comments, I think the speed portion is both the fastLiqSpeedin and fastRatchetSpeedb parameters.
fastLiqSpeedin is roughly just initialBudget divided by the # of days in the initial exit period. Liquidity is released on a per-block basis, so liquidity is always being injected into the RAMM and if params are updated, it will still be injected on a per-block basis.
If people are unhappy with the fastRatchetSpeedb, what would be the proposed update to that speed?