Iāve brought up the idea of Redemptions as an improvement to 1Hive a few times recently and wanted to take the time to do a more in depth write up explaining what exactly I mean by it, and why I think it would be good for 1Hive to implement.
Simply put, Redemptions would allow Honey to be exchanged for a proportional share of liquid assets in the 1Hive treasury.
For example, letās say there is 100 Honey in circulation, and the treasury holds 100 Dai and 10 Ether, if someone were to redeem 50 Honey, they would receive 50 Dai and 5 Ether. The new state of the system would be 50 Honey in circulation and 50 Dai and 5 Ether in the treasury.
While the mechanism is fairly straightforward, the impact on the dynamics of Honey and the incentives within the 1Hive community are significant and imo very positive.
- Establishing a price floor based on the value of liquid assets in the treasury.
If Honey holders are the beneficiaries of the 1Hive treasury (which they are imo). Then there is no justifiable reason for Honey to ever trade below the value of liquid treasury assets. Considering the value of current and past investments, brand value, etc it should realistically always trade at a premium to the liquid treasury value.
Redemptions would enable people to arb the price of Honey relative to the liquid treasury assets, which would effectively establish a price floor and prevent Honey from trading below that value for any extended period of time.
- Allocating treasury funds using conviction voting
The core governance mechanism of 1Hive is to allocate Honey from the common pool in order to fund contributions that bring the most value back to the community.
Conviction Voting is used to regulate how Honey flows from the common pool for this purpose, it ensures that common pool value doesnāt disappear over night, and allows for minority interests to be fairly represented in fund allocations.
This is why the required conviction for a funding proposal depends on how much is requested, and if you request to much of the common pool may even require more than 100 percent conviction and not be possible to pass at all.
Due to the disconnect between the value of the 1Hive treasury and the common pool, we have found ourselves in a situation where there is relatively little value available to request in the common pool compared to the treasury. And we are starting to see proposals which seek to spend treasury funds directly in order to circumvent the common pool and conviction voting mechanism that is used to govern 1Hiveās community funding mechanism. (1)(2)
While redemptions wouldnāt prevent people from trying to circumvent 1Hiveās governance since it would still be possible to petition the treasury multisig, it would help alleviate the pressure to do and social acceptability of such proposals by ensuring that there is a link between Honey in the common pool and the value of the treasury.
In the context of gardens v2 Iāve seen it suggested that we might have many pools with different assets all controlled by Honey using conviction voting so we should not be concerned about this, since we would be able to allocate treasury funds using conviction voting in that wayā¦ however such a scheme would still require the treasury multisig to fund this pools first, which is problematic (see the next point), and both unnecessary and overly complex if we were to redemptions.
- Reducing dependency on multisig governance
While having a treasury multisig has been a huge boon and necessary part of 1Hiveās governance, it is also a huge issue from a decentralization and automation perspective.
Multisig governance does not have the same guarantees about how funds are used that the common pool does, a faction of multisig holders could collude and empty the treasury in a manner of minutes at any time for any reason. Currently the council safe requires 4 signatures of the 10 members.
Redemptions would not solve the problem of a rouge faction of 4 signers rugging the community (though we can and should fix that too!)ā¦ it would be a step in the right direction since it would enable individual honey holders to exit if they disagreed with how the multisig was being used or allocated. It would also allow indivdividual honey holders the ability to leverage the treasury to impact the price of Honey, rather than depend on them to take ongoing action to buy Honey from the market to maintain a āsoft pegā as suggested recently by Paul as an alternative to something like redemptions.
- Concentrating Honey in the hands of aligned stake holders
Initially, or perhaps even before, when redemptions gets implemented there is likely to be significant correction involving Redemptions and buying of Honey that will result in higher price for Honey and a reduced value of the treasury.
It is hard to predict where the treasury value will stabilize, but it would be reasonable to expect price to stabilize relative its initial redemption value in the short term.
Whatever the case may be, the result of redemptions will concentrate the value of each remaining Honey in circulation. Given a circulating supply of 50k currently, if you have 1K Honey you own 2% of 1Hive, if redemptions reduces the supply to 25k, that same 1K honey is now 4% of 1Hive. While redemption value / price is still the same regardless of how many other people redeem, your upside in terms of potential growth is much much higher.
I suspect this will be incredibly healthy for the dynamics of contribution and speculationā¦ anecdotally I have heard contributors in the past who felt like they were working hard for the benefit of useless speculators who bought honey cheap back in the day and that they didnāt really like thatā¦ this outlook is toxic for the community. But itās not an unreasonable position given where 1Hive is/was. My hope is that redemptions would help bring the state of Honey (if viewed like a cap table) into a much healthier state and allow speculative investors and contributors to become more closely aligned in purpose.
ā
This has gotten pretty long already, but hopefully it helps better explain my thinking and rationale on this. I have some thoughts on possible implementations, but Iāll add them a bit later.
