Our first quarterly redemption has recently came to an end. While it went smoothly for the most part, I believe it also showed some flaws of the current WIP.
Let me preface by saying that while issue #1 was already possible under the TM’s authority, it would be a change to the original proposal by making the option explicit. Issue #2 is simply providing clarification on the intent behind the original proposal to ensure future redemption are done as expected and without confusion.
Betswapp & BSGG will be used as an example, but this could apply to other future VC assets like CTA.
VC assets should be handled differently when possible to avoid dumping on everyone and they should be divided by the circulating supply not the whitelisted supply.
For reference: [WIP #9] - Quarterly Redemption Option for Holders
Many holders had concerns around including assets like BSGG based on the fact that they are potentially meant for the long term (e.g. seed investments) and including them would mean dumping on holders, the treasury, and limit the upside of the investment.
Unfortunately, this redemption did just that (other than for those who sold before the price crashed). In this situation, it was a loss for mainly everyone. The redeemers, the holders and Betswap.
However, given it was voted that people who redeem should still have access to the allocated portion of these assets, there should be away for this to be a win-win-win.
That being said, in order to prevent another situation like this once here are options being proposed:
- The affected company (e.g. Betswap) will be offered the opportunity to buy the asset (e,g, BSGG) eligible for redemption through an OTC trade at market price (with the possibility of negotiating a lower price) prior to the redemption period.
- If a deal cannot be reached the assets can be sold OTC to someone else or redeemed.
- Vesting the redeemable assets to limit a big sell off
Please feel free to propose any options you feel may help the process.
As per WIP #9, the redemption price and a full breakdown is to be announced prior to the whitelist period.
This was to ensure that everybody had a clear understanding of what they would receive if they were to exchange their wMEMO. While the liquid backing in USDC was pretty clear, there was confusion around the amount of BSGG.
The initial amount of BSGG per wMEMO was around 57k. This was the amount announced prior to the whitelist and the amount that was promoted through the forum and Discord.
However, when redemption came, the amount of BSGG per wMEMO was closer to 229k.
This is mainly due to the clause of WIP #9 that says:
**Up to 25% of any VC assets that are considered liquid will be redeemable. The final percentage allocated will be determined by the Treasury Manager and announced as part of the redemption price prior to the redemption period.
The intention behind this clause was for the protocol and holders to benefit from these longer-term investments as well as serve as an incentive to remain in the protocol. Backing per wMEMO will increase due to the redeemers leaving a portion of the assets backing their wMEMO behind.
Unfortunately, this was interpreted as the whole allocation should be distributed to those who redeem. While in this situation redeemers received close to full backing (pre-dump), this interpretation comes with a few issues.
- Increasing the amount of VC assets being released/dumped hurting price action even more.
- Unclear redemption price/assets beforehand.
- The less redeemers the more they get.
- Last redemption, if only one person would have redeemed, they would have been eligible for 329m BSGG tokens (worth about 6.6 million USD at the beginning of redemption).
- Goes against the narrative that 1 wMEMO is worth a certain amount/percentage of treasury assets.
To help with these issues, it is being proposed to clarify that the amount of VC assets (0 to 25%) distributed per wMEMO should be based on the circulating supply, just like the USDC portion, and not based on the amount of wMEMO being whitelisted.
In the case of the last redemption, 57k BSGG per wMEMO would have been used and not 229k. This would have resulted in around 77 170 020 BSGG being released instead of 310 145 224 BSGG.