Discussion: Honey Issuance Policy

[lkngtn]

Currently we have a per block issuance rate which compounds, this is currently set at approximately 60% per year. Edit: the current issuance policy has since been reduced by half and is currently approximately 30% per year rather than 60%

Issuance is hugely important for bootstrapping a DAO in the absence of fee inflows, it ensures that the DAOs asset is flowing and circulating to contributors, rather than getting stuck in the hands of people who may have contributed a bit and then moved on to something else. Once fee inflows are established, value can continue to flow and circulate without issuance, but if value flow ever slows or stops a DAO is as good as dead.

If issuance is too low during the bootstrapping phases, people who contributed a little bit early on and then disappeared reap massive rewards. With issuance set too high, contributing tends to feel less valuable due to the potential for rapid dilution.

Finding the right balance is critically important. Currently honey holders can use governance to adjust the issuance policy (status quo), but discretionary governance over such a critical and central policy is not ideal and doesn’t really align with the governance minimization philosophy that makes 1hive unique. This was not a major concern until recently as 1hive was a much smaller, more tightly coordinated community operating under different trust assumptions.
However now that we have significantly more capital in the honey economy and we have a rapidly growing community of stakeholders establishing a clear, predictable, and more algorithmic supply policy should be a priority.

TLDR: The current issuance policy and governance mechanism controlling it needs to be replaced, the question is when and with what.

Some options:

1. We can disable issuance for now, relying on the existing common pool funds until we can research, model, and propose a more robust issuance mechanism. The main advantage here is it assuages concerns over the current issuance policy, but gives time to carefully consider better alternatives before committing to any specific policy.

2. We can issue a fixed amount of honey per block, ensuring that issuance is predictable and decreases over time instead of compounding if left alone. If we want we can also set block intervals, where this rate decreases over time similar to bitcoin. The main advantage of this approach is that its super easy and familiar for crypto people to understand… the main downside is that it doesn’t adapt based inputs so committing to a naive policy now may lead to challenges in the future.

3. We can issue a dynamic amount of honey per block based on the percentage of the supply that is currently in the common pool. Issuance would be 0 so long as there is some minimum percentage of the supply in the common pool, and increase as the balance of Honey in the common pool approaches 0. If fee inflows are greater than outflows, issuance can remain at 0 indefinitely while still ensuring that honey is circulating to contributors. Keep in mind that conviction voting limits the maximum rate at which funds can leave the common pool, so voting to abstain in conviction voting then also becomes a signal to decrease the issuance rate if the common pool is bellow the minimum threshold.

4. ???

EDIT: The issuance policy has been updated to 30% per year since this post was made.

[theJeweler]

Where would I find the current issuance policy?

[lkngtn]

You can see the issuance app in the dao here https://aragon.1hive.org/#/0xe9869a0bbc8fb8c61b7d81c33fa2ba84871b3b0e/0xb9fb2ad5820ccd9fd7bd6a9e35f98b22914db58a/

It shows up as 19.9% due to the frontend assuming 15 second block times (ethereum), rather than 5 second (xdai). The issuance app code can be found here https://github.com/aragonone/issuance-app/blob/master/contracts/Issuance.sol

This is far from adequate documentation on such an important thing, but it’s what we have currently.

[Herve]

Luke,

Thank you for the proposal.

I believe option 1 can be the most adequate decision and a clear signal of our commitment to continuously improve 1Hive Community Ecosystem.

Let us take the tme to think in the best equation / that might to include part of option 3.

FYI: Chile is voting for a new constitution in 2 Weeks after 40 years . Issuance is a key area that will impact in different dimension our Future organic growth.

Let’s vote !!

Bests,

Hervé

[Harry]

Thanks @lkngtn for following up our Discord discussion here.

For the very short term I do not think it is needed to stop the current issuing method, but for a longer term vision definitely. So my vote would be a combi of all 3 mentioned above:

• For now, switch to a fixed daily supply (maybe based on average supply over past 2-4 weeks?). Note that you mentioned:

ensuring that issuance is predictable and decreases over time instead of compounding if left alone.

This is not entirely correct; if the issuance is constant in absolute numbers, it does not decrease. The effective inflation does decrease though, which was my main concern.

So, if this could be changed easily, then we could have some further discussions about whether to stick with this, use your option 3 or a completely new model, based on the trading price, liquidity, total social cred etc.

Cheers, Harry

[linca]

I agree with Herve, start with option 1 for now and take the time to think for a longterm solution.

[Eth_Man]

Only a few comments.

We are going to have Honeycomb farming coming on-line. Also the price and hence the value of Honey is probably going to be quite volatile.

For the farming returns I think having a fixed issuance as well as a fixed amount of HNY going to LP rewards would be beneficial to be able to have some predictable value on longer term farming returns - also we don’t want issuance to have to increase/decrease based on HNY price.

I think having a fixed issuance (2) is a good choice because it creates predictable inflation and basically has the highest value rewards early in the system which decays over time. This is an easily adjustable metric so if a community reset is needed just up issuance. If everything is stable and humming along one could just let it continue to drip out. Most of this stays in the working fund anyway and is allocated via proposals so the ebb and flow of what is in the distribution account will be managed by governance and proposals anyway.

I do think some community discussion is warranted just to get a feeling for what people think so welcome this thread and discussion.

[lkngtn]

@Eth_Man

For the farming returns I think having a fixed issuance as well as a fixed amount of HNY going to LP rewards would be beneficial to be able to have some predictable value on longer term farming returns - also we don’t want issuance to have to increase/decrease based on HNY price.

I’m not sure I follow completely this point. The current plan for farming rewards is for people to propose pools, and create conviction proposals to fund them from the common pool. When funded the rewards are distributed over time to LPs who stake in those pools.

The reward amounts per pool are not the same, some pools may be rewarded more than others, and the overall rate of rewards is constrained by conviction votings budgeting/prioritization mechanisms (both between pools, and between other distribution mechanisms like pollen or the faucet).

I would be strongly against any sort of direct issuance that bypasses the common pool --> conviction voting flow, as that system is designed carefully to reduce argument surface.

@Eth_Man

I think having a fixed issuance (2) is a good choice because it creates predictable inflation and basically has the highest value rewards early in the system which decays over time. This is an easily adjustable metric so if a community reset is needed just up issuance.

I think that we can’t have it both ways, if it is “fixed” then it is predictable, but if it is “easily adjustable” then it is inherently not predictable.

[Eth_Man]

@lkngtn

I would be strongly against any sort of direct issuance that bypasses the common pool --> conviction voting flow, as that system is designed carefully to reduce argument surface.

@Eth_Man

I think having a fixed issuance (2) is a good choice because it creates predictable inflation and basically has the highest value rewards early in the system which decays over time. This is an easily adjustable metric so if a community reset is needed just up issuance.

I think that we can’t have it both ways, if it is “fixed” then it is predictable, but if it is “easily adjustable” then it is inherently not predictable.

I think after learning more I want to change my vote/view to use the current system as is after @lkngtn explained his chart I think I have some better understanding than before I made the above comments. I am going to leave them there for posterity but via this post and the last CC call based on new info change my view to just keep doing what we are doing and only if issues come up should we revisit this.

Right now I don’t see any massive problems with how issuance is going since basically common pool still has to go through conviction voting, be approved before any funds are sent out. I think some of the mechanics @lkngtn discussed around proposal submission, funding, and performance measures/metrics are important. But that is somewhat unrelated to Issuance policy generally.

[pauly]

Hey Everyone! I am new to the community and would like to share some thoughts on the issuance dilemma. In this reply I go into further detail looking at potential schemes based on Ikngtn’s original post.

The Dilemma

I agree, a 60% yearly compound inflation is simply way too high of an issuance level and should be replaced. That during the bootstrapping phase inflation needs to be high enough to reward the hive & LPS adequately yet prevent early hodlers from too much marketshare. It then needs to deflate relatively quickly to avoid too much value dilution. Devs and community need a consistent payout and that is easily understood by future LPs and Investors. This point should not be taken lightly. The easier it is to understand the economics of a token the more likely an investor or LP will join this party rather than another. Below is a supply proposal for idea (2) and a 4th issuance idea.

Fixed Issuance (2) a + b

(a) 1000 HNY per month issuance released into the number of blocks per month. More inflation means higher spending potential but at a cost of higher token devaluation.

(If each xdai block is 5 seconds and there are around 2,630,000 seconds per month, that will give you around 526,000 blocks per month. Divide 526,000 blocks by 1000 hny gives you 1 hny to distribute evenly among every 526 blocks)

eg @ 12000 Hny Per Year Inflation
Year 1 | 37,000 | 48 %
Year 2 | 49,000 | 32 %
Year 3 | 61,000 | 24 %
Year 4 | 73,000 | 19 %
Year 5 | 85,000 | 16 %
Year 6 | 97,000 | 14 %
Year 7 | 109,000 | 12 %
Year 8 | 121,000 | 11 %

(b) 500 HNY per month issuance released into the number of blocks per month. Less inflation means higher token appreciation but less spending potential.

(If each xdai block is 5 seconds and there are around 2,630,000 seconds per month, that will give you around 526,000 blocks per month. Divide 526,000 blocks by 500 hny gives you 1 hny to distribute evenly among every 1052 blocks)

eg @ 6000 Hny Per Year Inflation
Year 1 | 31,000 | 24 %
Year 2 | 37,000 | 19 %
Year 3 | 43,000 | 16 %
Year 4 | 49,000 | 14 %
Year 5 | 55,000 | 12 %
Year 6 | 61,000 | 11 %
Year 7 | 67,000 | 10 %
Year 8 | 73,000 | 9 %

Pros: Simple, fixes high compound inflation and easy to integrate and describe.
Cons: No hard cap, infinite supply. Rudimentary share weight distribution.

Dynamic Issuance (4)

Dynamical Calculate inflation based on liquidity offered. To Put it simply, the more bees in the hive the less honey is created. The less bees in the hive, the more honey is created. So based on the amount of liquidity in the system more honey is pumped out. This incentivizes early adopters when HNY is valued less and balances booms and busts cycles with a more consistent valuation of the honey in the pot. So what would this look like mathematically? I’m not sure really maybe some one more advanced can help figure that one out but something along the lines of this?

Total Locked Liquidity / (Multiplier) = Honey Supply Per Month

1,000,000 / (Multiplier) = 1000 hny per month
10,000,000 / (Multiplier) = 100 hny per month
100,000,000 / (Multiplier) = 10 hny per month
1,000,000,000 / (Multiplier) = 1 hny per month

Pros: Awards more honey when less liquidity flowing through platform. Awards less when more liquidity (effective automatic QE tightening and easing)
Cons: Harder to describe and implement. No hard cap, infinite supply.

Proposed Action

1. Continue hive minding issuance ideas.
2. Propose Vote to change Issuance and then vote on the favorite model found.

[befitsandpiper]

I think there there is no need to change the issuance policy we have currently in the near term. But I would really like to see option 3 become the policy of choice once we’re ready and are clear on the implementation details.

This option has very nice properties, and it assures that the common pool can never fall to zero. The common pool falling to zero would destroy many of the mechanisms we have set up for the hive to manage and create value. It also incentivizes revenue producing projects, since more revenue means lower inflation, and even deflation.

During high growth time periods where we are focused on project expansion, issuance will be high, and during less active humdrum times, issuance will contract and so inflation should decrease. This seems like a perfect counter to the hype cycle, and so should make the price of honey more stable in the long term.

[Escanor]

I think option 1 should be the way to go.

[s_ben]

So I’m relatively new to the community, and by no means an expert on monetary policy. But have been observing other monetary experiments in the space, and in SourceCred we’ve talked a bit about similar ideas.

@lkngtn

2. We can issue a fixed amount of honey per block, ensuring that issuance is predictable and decreases over time instead of compounding if left alone. If we want we can also set block intervals, where this rate decreases over time similar to bitcoin. The main advantage of this approach is that its super easy and familiar for crypto people to understand… the main downside is that it doesn’t adapt based inputs so committing to a naive policy now may lead to challenges in the future.

While a fixed issuance policy is attractive to some (indeed a requirement for many that prioritize “sound money”), I see a couple potential issues.

• High inflation = high sell pressure. Many of the coins that came after Bitcoin copied the inflation schedule. This seems to have worked well for some early Bitcoin clones. However, many “next gen” coins that launched a few years later (e.g. Zcash, Decred, Dash) have struggled to maintain their valuations. This is often attributed to the high sell pressure caused by being earlier on the inflation curve than Bitcoin. This is particularly bad in a bear market, when buyers are more scarce. Dash was able to change consensus rules recently to reduce supply, with the explicit aim of improving market cap. But that change took a considerable amount of effort, caused a bunch of drama, and was likely only possible due to relative centralization.

• Inflexibility. I just listed to a podcast on Bitcoin’s monetary policy where Dan Held says that Satoshi originally wanted a mechanism to modulate inflation. But there was no input or mechanism that could be trusted. Hence the deterministic exponential curve. This predictability may be a strong meme, but challanges around it have emerged. The fee market may never be enough to secure the network when inflation decreases, for instance. In the meantime, other models that are more flexible have emerged that seem to be holding. E.g. Monero with its tail emissions, ETH with its political process that has delivered less inflation than predicted, and now an explosion of new PoS and DeFi projects testing out all types of new dynamic issuance policies. These recent advancements and successful (thus far) projects may point to more flexibility being possible.

@lkngtn

3. We can issue a dynamic amount of honey per block based on the percentage of the supply that is currently in the common pool. Issuance would be 0 so long as there is some minimum percentage of the supply in the common pool, and increase as the balance of Honey in the common pool approaches 0. If fee inflows are greater than outflows, issuance can remain at 0 indefinitely while still ensuring that honey is circulating to contributors. Keep in mind that conviction voting limits the maximum rate at which funds can leave the common pool, so voting to abstain in conviction voting then also becomes a signal to decrease the issuance rate if the common pool is bellow the minimum threshold.

As a contributor looking to make my income from DAOs moving forward, I like this idea. We’ve discussed something like this in SourceCred. A “rainy day fund” is not only a tested budgeting tool in traditional budgeting, it is easy for a contributor to understand and validate. If I’m a contributor evaluating whether to contribute to a project, and I can see, on the blockchain, a pool of common funds, and I can also understand and validate how those funds are distributed, I can have stronger guarantees around future income.

A tricky part here is the threshold. Is a minimum percentage of the supply pool enough to pay contributors and other expenses? Depends in part on a) the inflation schedule, b) the number of contributors, and c) market cap? In general I think hard thresholds are dangerous. They become targets for gaming and if conditions change become barriers to getting things done (e.g. the pool is too small to get something done).

@lkngtn

???

On the faucet page, the faucet is compared to the early distribution of Bitcoin and Ethereum.

Already, this seems to be working as intended. It seems the large influx of people 1Hive has seen in the last couple weeks has been largely driven by the faucet (free HNY). The parallels to Bitcoin and Ethereum are striking. The amount of HNY decreasing every 48 hours, adjusted by the number of people registered, is similar to Bitcoin’s PoW difficulty adjustment algorithm. But with BrightID-verified humans instead of computers, it is literally achieving Satoshi’s vision of 1 CPU = 1 vote! The main difference is that instead of Bitcoin or Ethereum miners burning electricity, they’re burning their attention. Which is a fine substitute for electricity. Web 2.0 platforms have proven now that attention is, quite literally, a commodity. Bought and sold like electricity or any other commodity. Add in regular “halvenings” in the amount of honey distributed, and you’ve recreated a more pure Bitcoin. Amazing! To stretch the analogy further (unless this is just the design and I’m just realizing it ), conviction voting would be like the consensus algorithm. Proposals are submitted to the “mempool”, or proposal pool, and “miners” (HNY holders) vote on whether the transaction is valid (the proposal gets paid).

So I guess I’m just wondering, why not use this?

Or could it be an input to the issuance policy?

I did a similar thought experiment with Cred in SourceCred, where PoW was replaced by PoC (Proof-of-Cred). Probably not too feasible, but it was a fun exercise, and @mzargham mentioned in chat that while crude and poorly designed, it belonged to a type of known regulatory mechanism for dynamic systems

SourceCred as Store-of-Community Value (SoCV)

Already, the faucet and SourceCred seem to be interacting. People come for the faucet, some discover SourceCred and get excited and decide to contribute more. Kinda like a funnel… Perhaps the next stage of the funnel is conviction voting, providing liquidity, or otherwise become a made bee . But I digress…

Anyway, apologies for the long reply. Many thoughts buzzing:)

[Jasper]

Lots of interesting stuff to digest in your post. Also loved the post you linked on the SC forums. A bit off topic but I think over the next few weeks the growth of the 1hive community will expose some of the growing pains of sourcecred. I have thought about how it’ll play out so I’m very curious to see what actually happens.

Back on topic, the issuance policy is the amount of HNY that goes straight into the common pool, whilst faucet top ups are taken from the common pool. For the faucet to be an indicator for the issuance policy it should directly relate to the amount of HNY in the common pool, whilst it currently completely depends on proposals. So I’m not sure I understand completely how you would see the faucet relate to the issuance policy. After thinking about it some more I understand the indirect relationship between conviction voting and issuance as also suggested in Luke’s original point three, but the link between the faucet and the issuance policy still doesn’t quite click for me.

[Gt88210]

@lkngtn

community operating under different trust assumptions.

Option #1 seems like a responsible approach. This is still new to me Im glade to take part of it

[s_ben]

@Jasper

Lots of interesting stuff to digest in your post. Also loved the post you linked on the SC forums. A bit off topic but I think over the next few weeks the growth of the 1hive community will expose some of the growing pains of sourcecred. I have thought about how it’ll play out so I’m very curious to see what actually happens.

Indeed veered off topic at the end, sorry about that. Just got a little carried away, and some of my more out there thoughts on SourceCred were merging with out there thoughts about the faucet. There will be growing pains with SourceCred, sure. But SourceCred is here to support, and my sense is that 1Hive is a good place to experiment.

@Jasper

So I’m not sure I understand completely how you would see the faucet relate to the issuance policy. After thinking about it some more I understand the indirect relationship between conviction voting and issuance as also suggested in Luke’s original point three, but the link between the faucet and the issuance policy still doesn’t quite click for me.

Right, it’s all a bit mashed together in my head. Lots of moving parts, lots of indirect relationships. I suppose I’m kind of thinking of the common pool as the source of issuance, not the blockchain. So like if you just directly tied issuance of new coins to distribution of new coins (i.e., X coins go out the faucet, X more coins are created by the issuance policy). This is probably a bad idea. However, my sense is that we’re seeing emerge in 1Hive new possible dynamic feedback signals/mechanisms. Proof-of-Work in Bitcoin wouldn’t have worked without the difficulty adjustment algorithm. It did achieve a level of Sibyl resistance (its main aim). However, building mining rigs and burning electricity is a rather crude (if robust) signal. New Sibyl resistant signals such as unique human attention, value created, and value distributed via conviction voting, etc., could be valuable in creating higher-level “consensus” algorithms directing value at the DAO/hive level.

[solarmkd]

I am thinking that 3rd option is the best for now. It looks efficient like Bees are,just mint enough currency to have enough for :

1. Liquidity incentives
2. Faucet and Cred
3. Funding various proposals ( Development, Marketing, Incentives, Partnerships )

Now of course we would need to come up with some stats for this so here the 1st option kicks in as we dont have enough experience and stats to come up with exact minting algorithm.

Those are just some of my thoughts for now but in general i can see we are on same page.

[lkngtn]

@s_ben

On the faucet page, the faucet is compared to the early distribution of Bitcoin and Ethereum.

I think there is an important distinction between the issuance policy and the distribution policy, in the case of 1hive we have conviction voting as the core distribution policy, and then we have a number of things which are extensions of that like the faucet and pollen and liquidity mining (and likely lots of novel things in the future). But the issuance policy (how things get minted) is currently just a per block issuance rate… In the case of bitcoin this would be the block reward schedule, and proof of work would be the distribution policy, they are related but distinct mechanisms.

@s_ben

A tricky part here is the threshold. Is a minimum percentage of the supply pool enough to pay contributors and other expenses? Depends in part on a) the inflation schedule, b) the number of contributors, and c) market cap? In general I think hard thresholds are dangerous. They become targets for gaming and if conditions change become barriers to getting things done (e.g. the pool is too small to get something done).

I think since we are denominating things in terms of a proportion of the supply, I don’t think it makes sense to think in terms of expenses or budgets per se. The value of the common pool will fluctuate based on the value of honey and the network as a whole, which is good it keeps everyone aligned around creating value together, but it also means that the budget will expand or contract with the market. It will always be “enough” because the ability to spend money will automatically contract or expand to fit the budget.

Instead I think we should be thinking in terms of flows, the we want to ensure that there is always a sizable portion of the the supply that is flowing through to contributors. If we don’t then contributors are just working to make a bunch of early speculators more wealthy, and thats lame. This is fundamentally the issue that bitcoin and ethereum face as well, it often makes more sense to go start a competing chain than to contribute, because there isn’t a built in mechanism to re-circulate significant value to new contributors. By setting a minimum percentage of the supply as a target we can guarantee that recirculation occurs no matter what (either via issuance or fees), and we can all align as stakeholders around the idea that if we want to minimize dilution we need to work together to generate more inflows than outflows (but we can’t do that simply by turning off outflows).

[s_ben]

Thanks for the further explanation @lkngtn. Very cool how well thought out everything I’m encountering is. Keeping a certain amount of new circulating supply going to contributors as a general design goal is not something I’ve seen put in action before, seems very promising.

[Harry]

It’s clear that both projects that ‘keep’ 30+% of available tokens for dev + seed etc are not sustainable, but on the other hand 0% projects also normally don’t work. So we must find a good balance and likely this must be re-assessed every few months.