Understanding 1Hive’s dynamic supply policy for $HNY
Intro
As this is not an article on the topic of what 1Hive is, I still welcome anybody interested to follow this link and find out for themselves what this specific decentralized autonomous organization is working on.
In this article, I will explain how 1Hive’s planned Dynamic Supply Policy works. In order for this article to be accessible to everyone, the first part of it will be structured as a crash course on the current HNY tokenomics so that someone relatively new to 1Hive can understand how they work. The second part will be a formal explanation since it is the central part of the discussion. Please feel free to skip ahead to “The Dynamic Honey Supply Policy” if you are only interested in that part of the article.
Crash Course Honey Tokenomics: Abstract
The first and most important points to remember:
1Hive is at its most basic a community that has a community currency which reflects how productive the community is through a “feedback loop” that is closely tied to its issuance and supply policy.
A feedback loop is in essence just a thing (machine) that takes the output from another thing (machine), possibly does operations upon it, then returns it to the sending thing (sending machine) as input.
It’s also the defining building block of a conscious entity (you do things, receive feedback, then your further actions take that feedback into account), but also many systems which are prominent in computer science (see neural networks) and engineering in general (operational amplifiers, control loops for devices that need to regulate highs and lows of any quantity).
The most basic “loop” for 1Hive is relatively simple when looked at from afar. Let us assume that just “magically”, without us having to know exactly how, the HNY price reflects how productive the community is. Then;
Set HNY price to 1$ → Community is productive for some random reason→ HNY price rises to 2$ → Community does more work → 3$ → Community slacks off → 2$ → “Yikes! We have to do something!” → 3$
And so on, hopefully ad infinitum. It is very obvious how the HNY price is changing according to the productivity of the community. Please do note that these are just sample prices, the price of HNY as of the time of writing is about 1400$.
Crash Course on the current Honey Tokenomics
Now that we understand our “magic” system we can explain in a little more detail on how the supply policy works at the time of writing and how this has an influence on our feedback loop.
So first of all we need to learn what issuance is and how it ties in with the HNY supply. From the wiki:
Issuance refers to the process that mints new Honey. Honey is currently set to increase in supply at a rate of 30% per year. The current issuance policy allows anyone to call a function to mint Honey to the common pool and the amount of Honey issued depends on the issuance rate parameter and number of blocks which has passed since the last time the function was called.
Keep the bolded parts in mind and please take a look at the following HNY flow diagram (diagram of where HNY is minted, where it flows to):
The most important objects in this diagram are the “Common Pool”, “Honey Supply” and the “Honey Issuance” cloud. We are also going to be looking at the “Supply Policy” diagonal.
So how does this diagram tie in with the formerly mentioned definitions?
The “Honey Issuance” cloud is just an object that can issue Honey (HNY), when Honey is issued it flows into the the “COMMON POOL” of 1Hive, BUT it also “flows” into the TOTAL “HONEY SUPPLY” because the Honey Supply is just the sum of the Honey in the Common Pool and any Honey outside of the Common Pool (in wallets). The Circulating Supply on the other hand, is all the Honey that is not inside the Common Pool. The main point of attention of this article will be the arrow connecting the Honey Issuance cloud to the Common Pool.
I set the “flows” into the Honey Supply under quotation marks because the Honey Supply is actually not an existing object, Honey cannot flow into it per se, but the Honey Supply is obviously the sum of all Honey, so if new Honey flows into ANYTHING, Honey also abstractly flows into the Honey Supply.
What the “Supply Policy” line basically represents is how the Common Pool balance is connected to the Total Honey Supply. Any change in the Common Pool will affect the Total Supply immediately. Thus, issuance is linked over the Supply Policy diagonal to the Total Supply in some way.
Now, repeating from earlier:
Honey is currently set to increase in supply at a rate of 30% per year.
This is referring to the total supply of Honey. In essence, looking beyond just our issuance and supply policy, our whole mechanism can be summarized as follows:
Mint Honey and send it into the Common Pool (our arrow), so that in one year, the total Honey supply increases by approximately 30%. If a conviction proposal passes asking for Honey, distribute it to the contributors. Use our products and the associated fees, which are connected to the Common Pool, to buy back Honey from the market, and store it in the Common Pool, to increase the Honey price, and recycle Honey for new distributions, instead of minting new one.
This is exactly what the above diagram wants to explain.
From the Wikipedia:
The value of Honey is determined by supply and demand. The supply is managed by an issuance policy and demand can be influenced by participating in the process of staking on proposals that allocate and distribute Honey from the common pool to contributors.
If participants allocate Honey productively, inflows to the common pool will eventually exceed outflows, demand will outpace supply, and the value of Honey will increase. Conversely, if Honey is allocated unproductively the circulating supply of Honey will increase without a corresponding increase in demand and the value of Honey will decrease.
The above is a slightly more detailed explanation to bind things together. Contributors use Honey to make products that have a positive impact on the price of Honey. Better governance means we are a stronger DAO, which means that Honey becomes a more valuable governance token. Honey buybacks increase the scarcity of Honey, directly affecting the Honey price and also benefiting holders and liquidity providers alike. All of this can only be assured if the issuance and supply policies are in harmony to assure that they do not undermine our productiveness and adapt to possible lacks of productiveness.
I am going to repeat the issuance part from the above diagram summary:
Mint Honey and send it into the Common Pool (our arrow), so that in one year, the total Honey supply increases by approximately 30%.
This is the current state.
Dynamic supply — why?
For this part, I would like to refer to Luke’s (a 1Hive seed member) post on why we are switching to the dynamic supply model. Note that since issuance is closely tied to the supply, if the our issuance model is dynamic, we can also call our supply model dynamic. The following quote:
Currently we have a simple issuance policy that allows anyone to mint honey to the common pool at a fixed rate per block. This rate can be updated via governance decisions 2. Currently it is set at approximately 30% per year.
This is relatively high, and reflects the early stage of the community. Just like projects like Bitcoin and Ethereum had high issuance rates early on to help bootstrap a community and economy around their respective assets, the issuance rate for Honey is relatively high currently, and we expect it to be adjusted lower in the future. However, unlike these examples we have not yet codified a process for how the issuance rate is modulated, and instead have relied on governance to come to consensus and make changes as needed.
In line with our general philosophy we want to minimize governance over issuance. One way we could do that would be to replicate a “fixed supply” policy with emissions scheduled years in advance like Bitcoin… however because the goal of the system isn’t just to distribute a finite amount of tokens, but to ensure that the economic engine and incentives of 1Hive participants are aligned we needed to come up with a more sophisticated policy.
1. We want to be able to consistently allocate Honey to fund proposals as these proposals are used for development, promotion, and support of new applications that add additional utility to the Honey token.
2. We want Honey to remain scarce and increase in value over time.
To summarize this post, since we want the Honey price to appreciate we need to introduce an issuance policy that is more than just fixing a HNY minting rate that will lead to a 30% total supply increase.
One of the problems with the original system is that it cannot account for the inflows and outflows into the common pool. Secondly, there is no burn function at all. If we want to reach a stable ratio we need the system to adjust its minting/burning rates according to the current status of the Common Pool.
The Dynamic Honey Supply Policy
To solve the above-mentioned problem of not being able to let the HNY supply automatically converge towards a targeted yearly (translated into seconds) common pool-total supply ratio increase without repeatedly having to readjust the minting rate by hand, the Dynamic Honey Supply Policy is introduced.
The idea:
The Dynamic Honey Supply Policy introduces a proportional control function which is in essence a feedback loop. This control function adjusts the minting/burning of the Honey token according to the size of the difference between the target and present ratio of Honey in the pool. The whole system would look something like this:
This would also change our original diagram because now we have a burning function, we would receive the following:
The only question is now how the proportional control function actually exactly regulates the Common Pool balance.
The idea is the following, we will have two ratios and an error term:
The error represents how off our target ratio is from the current ratio, it has two advantages:
- If the current ratio is larger than the target ratio the function starts burning, so it has a switch.
- It is irrelevant what the numbers in play are, any changes are going to tend towards the target ratios, anything that we do with the error function after setting the target ratio can only influence on how much HNY is minted but not what ratio the HNY in the Common Pool tends to in relation to the total Honey supply.
I will denote these above as, error, current_ratio and target_ratio.There is also another value that we will add to these, this will be the throttle value. The throttle is just a cap on the maximum adjustment allowed so that the HNY supply does not become too volatile.
The following pseudocode snippet from Luke’s post, meaning just something that looks like code but is somewhere in between normal language, mathematics and code, explains how the error term is used then for adjustments:
error = (1 - current_ratio / target_ratio) / seconds_per_year
if error < 0:
adjustment = max(error, -throttle) * supply
else:
adjustment = min(error, throttle) * supplyIn essence, we are using our error value as an adjustment value. Now, theoretically, if we want to calculate our current common pool balance, we would multiply our total supply with our target ratio and then with the error. For our adjustment though, it is irrelevant which number we exactly use, as it only has an effect on the slope of the change of our HNY supply. In fact, supply could have been any number. The fact of the matter is though, that we have to be careful and adjust these parameters in order not to cause drastic supply changes as of the initial deployment, because if we were to take a 100x larger value instead of supply , our HNY mint, even if divided by the numberof seconds per year, would be huge.
It is quite obvious that choosing the right parameters, which seem to be the main regulators of our whole HNY supply, is very important.
As mentioned earlier though, there is another thing which we must model and these are the common pool outflows and inflows based on our productivity. As explained in Luke’s post:
…when productivity is too low, the system will not reach a significant percentage of market saturation, inflows will not offset outflows, and the supply will increase while the price continues to decline. If productivity is high, the system will reach and stabilize at a high level of market saturation.
…and if we are productive we should expect that to result in an increasing price and market cap for Honey over time.
This productivity parameter is abstract, we may be able to measure productivity of proposals in some way in the future and map that data back into the model, but for now it is just a value that is used to tune the model. Since we don’t know what it actually represents in reality, but we do know that our success is neither guaranteed nor impossible, we can choose an arbitrary productivity value that is neutral and allows us to examine how sensitive success or failure modes are to changes in the throttle and target reserve parameters.
This is very important for multiple reasons, first of all, because our error movement depends on the Common Pool outflows and inflows, which are in turn dependent on this productivity parameter. A sample error over time graph:
I have intentionally removed the axes numbering because this only one of many possible different error movements. The sudden jumps and trajectory changes from descending to ascending and back in fact represent where the control function switches from minting to burning and back. The number towards which the error is tending with time in this graph is zero.
Secondly, Luke was also talking about market saturation and our market capacity, let us look at the definition of market saturation:
Market saturation is economic terminology for a situation where a product is released and distributed into a market. How saturated that specific market becomes depends on how well it is received by consumers and, subsequently, their purchasing power. Other factors such as technology, competition and prices also all have an effect.
In essence, if our productivity is large, our market saturation will be large and our market capacity will be large. This is exactly what we want for Honey.
Below I will summarize the most important results:
The Luna swarm, which deals with financial modelling, has decided to stick here with a throttle parameter of 0.008, which is just under a maximum yearly issuance of 10%.
When this throttle parameter is now run through Monte Carlo simulations to calculate the possible Market Saturation, a large jump is seen from 0.2 to 0.3 target_ratio.
Further modelling seems to indicate a larger market capacity growth with the 0.3 and 0.4 values (denoted as 2 and 3 respectively), and overall better performance. The Luna swarm has opted for a 0.3 value since it closer to our current policy, not to have a volatile supply at the start.
Finally, through a lot of modelling, we have found the 0.008 throttle and 0.3 target_ratio value which will be the start point of policy. The only thing left is the actual Solidity implementation which can be found here:
I encourage newcomers to read it.
Finale
The above was an explanation of the proposed Dynamic Honey Supply Policy that will roll out with our Celeste product.
If you have any further questions I would advise anyone to join our Discord:
https://discord.com/invite/P4rRDUKTAU
Any ask your questions there!
